Chapter 3: Software Platform & Architecture for Telematics
Chapter 3: Software Platform & Architecture for Telematics
Chapter 3: Software Platform & Architecture for Telematics
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Content• ECU• Automotive Open System<strong>Architecture</strong> (Autosar)– An open standardized softwarearchitecture <strong>for</strong> the automotiveindustry– Special thanks to Simon Fürst,BMW• 1st AUTOSAR Open Conference & 8thAUTOSAR Premium MemberConference• October 23rd, 2008, Cobo Center,Detroit, MI, USA22010/2/3
ECU• Electronic Control Unit– 行 車 電 腦 , 車 載 電 腦– is an embedded system that controls one or moreof the electrical systems or subsystems in avehicle• CPU, memory, I/O, A/D, Other Devices32010/2/3
ECU• Some modern cars have up to 80 ECUs, including– Engine Control Unit ‐ also known as an ECU– Transmission Control Unit ‐ TCU• the above two may be combined, and referred to as a Powertrain ControlModule (PCM)– Airbag control unit ‐ ACU– Telephone Control Unit ‐ TCU– Man Machine Interface ‐ MMI– Body Control Module ‐ controls door locks, electric windows,courtesy lights etc.– Door Control unit– Seat Control Unit– Climate Control Unit– speed control unit– Convenience control unit ‐ CCU(From WIKI)42010/2/3
Exmaple of ECU1. Wheel speed sensor2. Rear differential oil temperature switch3. Wheel speed sensor4. Manual mode switch5. Manual control dial6. DCCD electronic control unit7. Parking brake switch8. DCCD indicator lights9. Battery10. ABS control unit11. Wheel speed sensor12. Brake light switch13. Throttle position sensor14. Accelerator pedal15. Wheel speed sensor16. Lateral G sensor (with yaw rate sensor <strong>for</strong> 2005)17. Main gear input from the engine18. Front output19. Rear output20. Transmission assembly21. Center differential22. ABS monitor signalResource: 5 SUBARU driver per<strong>for</strong>mance 2010/2/3
ECU• Based on in<strong>for</strong>mation from the inputsensors(engine coolant temperature,barometric pressure, air flow etc.) the ECUdetermines optimum setting <strong>for</strong> the outputactuators. (injection, idle speed, ignitiontiming, etc.)62010/2/3
AUTOSAR TutorialReferencehttp://www.autosar.org
Autosar• Cooperate on standards –compete onimplementation82010/2/3
Managing Complexity by Exchangeability andReuse of <strong>Software</strong> Components92010/2/3
Project Objectives and Main WorkingTopics102010/2/3
Main Working Topics112010/2/3
Technical scope of AUTOSAR122010/2/3
Benefits from AUTOSAR132010/2/3
AUTOSAR –Core Partners and Members142010/2/3
Use Case ‘Pedal Management’ view <strong>for</strong>one ECU• Implementation of functions independent ondistribution on different ECU as communication willbe done via ECU‐individual AUTOSAR‐RTE exclusively152010/2/3
Use Case ‘Pedal Management’ view <strong>for</strong>two ECUs162010/2/3
Use case ‘Front‐Light Management’ inAUTOSAR172010/2/3
Exchange of type of front‐light182010/2/3
Distribution on ECUs192010/2/3
Use case ‘Front‐Light Management’ inAUTOSAR202010/2/3
AUTOSAR Key Topics• AUTOSAR provides three main areas of results– <strong>Architecture</strong>:• <strong>Software</strong> architecture including a complete basic(environmental) software stack <strong>for</strong> an ECU as an integrationplat<strong>for</strong>m <strong>for</strong> hardware independent SW applications– Methodology:• Exchange <strong>for</strong>mats (templates) to enable a seamlessconfiguration process of the basic software stack and theintegration of application software in ECUs– Application Interfaces:• Specification of application interfaces as a standard <strong>for</strong>application software modules212010/2/3
Main Concepts: <strong>Architecture</strong>• Basic <strong>Software</strong> modules• Run time environment and communication• Results of sample implementation in„Validator 2“222010/2/3
Main Concepts: <strong>Architecture</strong>• Standardized AUTOSAR interfaces will support HWindependence and enable the standardization of SWcomponents.232010/2/3
AUTOSAR Basic <strong>Software</strong>242010/2/3
AUTOSAR Basic <strong>Software</strong> Modules252010/2/3
Intra‐ and Inter‐ECU Communication• Ports implement theinterface according tothe communicationparadigm (here clientserverbased).• Ports are theinteraction points of acomponent.• The communication ischanneled via the RTE.• The communicationlayer in the basicsoftware isencapsulated and notvisible at theapplication layer.262010/2/3
Validation of AUTOSAR Release 2.0272010/2/3
Used Release 2.0 AUTOSAR specifications282010/2/3
Used Release 2.0 AUTOSAR specifications292010/2/3
Development ofAUTOSAR SW ComponentsMarkus Maier / ETAS GmbHResource <strong>for</strong>m p.3‐7, 10
<strong>Software</strong>‐ and System‐<strong>Architecture</strong> of ECUs• Automotive <strong>Software</strong> Development will change• Hardware- and software will be widely independent of each other.•Development processes will be simplified.•This reduces development time and costs.•Reuse of software increases at OEM as well as at suppliers.•This enhances also quality and efficiency.312010/2/3
<strong>Software</strong>‐ and System‐<strong>Architecture</strong> of ECUs• Today: Proprietary <strong>Software</strong>‐<strong>Architecture</strong>322010/2/3
<strong>Software</strong>‐ and System‐<strong>Architecture</strong> of ECUs• Tomorrow: AUTOSAR – Standardized <strong>Software</strong> <strong>Architecture</strong>332010/2/3
<strong>Software</strong>‐ and System‐<strong>Architecture</strong> of ECUs• Today: ECU network342010/2/3
<strong>Software</strong>‐ and System‐<strong>Architecture</strong> of ECUs352010/2/3
<strong>Software</strong>‐ and System‐<strong>Architecture</strong> of ECUs• Future: Function oriented <strong>Architecture</strong> <strong>for</strong> higher Flexibility362010/2/3
<strong>Software</strong>‐ and System‐<strong>Architecture</strong> of ECUs• What disappears?– Proprietary Basic <strong>Software</strong> with proprietary interface towardsthe application software• What comes up?– Standardized Basic <strong>Software</strong> Modules– RTE (Runtime Environment) make application softwareindependent from Basic SW and specialities of ECU hardware– Application SW Components with standardized interfacedescription (syntax and specific signals)• What stays?– Application <strong>Software</strong> as a brand differentiating key element <strong>for</strong>the development of new vehicle functions372010/2/3
Development of AUTOSAR SW Components• Model based Methods and Tools ‐ Overview382010/2/3
Development of AUTOSAR SW Components• Following the AUTOSAR Methodology, theE/E architecture is derived from the <strong>for</strong>maldescription of software and hardwarecomponents.392010/2/3
Development of AUTOSAR SW Components402010/2/3
Development of AUTOSAR SW Components412010/2/3
Development of AUTOSAR SW Components• To configure the system, input descriptions of all software components,ECU resources and system constraints are necessary.422010/2/3
Development of AUTOSAR SW Components• The system configuration maps software components toECUs and links interface connections to bus signals.432010/2/3
AUTOSAR –System Design – Implementation Process442010/2/3
AUTOSAR –The Virtual Functional Bus• Input to the System Design on an abstract level452010/2/3
AUTOSAR –Input Descriptions• Step 1a): Description of SW‐Components independently of hardware462010/2/3
AUTOSAR –Input Descriptions• Step 1b): Description of hardware independently of application software472010/2/3
AUTOSAR –Input Descriptions• Step 1c): Description of system482010/2/3
AUTOSAR –System Configuration• Step 2: Distribution of SW‐Component‐Descriptions to ECU492010/2/3
AUTOSAR –ECU‐Configuration• Step 3: Generation of required configuration <strong>for</strong> AUTOSAR‐Infrastructureper ECU502010/2/3
AUTOSAR – Generation of <strong>Software</strong> Executables• Step 4: Based on the configuration in<strong>for</strong>mation <strong>for</strong> each ECU (exampleECU1)512010/2/3
Use case ‘Front‐Light Management’ in AUTOSAR522010/2/3
Change language