Single and Integrated Networking

Dedicated ECU of ECU

ECU for
1990

2005

2020
each
function.
Challenges

Electronics/electrical
complexity has developed
Software code is getting
longer
Many Hardware platforms
Non- harmonised processes
Bottom to top view
• Operating system : interface between application and the
microcontroller

• MCAL : micro controller abstraction layer

• Low level drivers and hardware abstraction layer, device layers
• Touches all MC peripheral resisters and gives a common API
• Provided by the silicon vendor

• Run-time-environment : abstraction for the user

MCAL
• System drivers : basic software manager, ECU manager,
• Mostly deals with the engine control unit
• Diagnostics modules and AMD
• Events manager other diagnostic activities
• AMD is used for debugging.
• Memory stack : EEPROM and volatile memory
• Communication modules

CAN LIN Flex-ray Ethernet

Protocol Data Unit
• Applications send and receive a PDU, this is mapped by various
processes in the work flow.
• Application can be developed independent of the physical bus.
• Thus applications can be independent of the OEM physical bus.
Function centric • Software component description
• Software components interacts with each
view other using a virtual bus
• Mapping them to ECU
• Finding already existing ECU creating a
• Requirements system description
• Mapping to • Extract of the system description
Functions • modularises the information for each ECU
• Mapping to ECU • ECU config. file
• Description necessary for the components
to be designed.
VECTOR services

1.PREE viewer
2.Da Vinci developer
3.Virtual Target
4.CANope
Automotive Open System ARchitecture
• Open and standardised software architecture
• Defines only the interfaces maintaining the freedom in the way of
obtaining the functionality
• Virtual function bus: connects various software models with the
design model.
• Conceptualisation of all hardwares and softwares of the vehicle system
• An abstract communication pathway between theapplications
Input Descriptions
• Software components
• Specifies only the hardware and requirements
• Actual implementation is not the goal of this step
• Software
• describes the inter connection between ECUs to achieve the required
functionality
• This description needs to be detailed
• Hardware
• Specifications of the hardware (sensors and actuators)
 • Distributes the software component to
System various ECU
configuration • An iterative process, balancing between ECU
resources and system-constraints

ECU • Configures the basic software and the run-

configuration time-environment of each ECU

Software • Generates the executables based on the

Executables implementation specified
Challenges with AUTOSAR
• Responsibility on the OEM to transform functional requirements into
AUSTOSAR components and put them together.
• Shift from the traditional top down design process to an AUTOSAR
focussed method.
• Unresolved technical issues needs to be sorted out before moving
ahead in the process