Historically, the automotive industry has taken a federated approach with each car function implemented in a separate box, but the growing trend is now to integrate more and more functions on to fewer ECUs. However, a significant development issue for automotive OEMs is that this multitude of ECUs will likely come from many different suppliers. The question becomes how do these ECUs communicate with each other and how can the system development be managed effectively?
AUTOSAR
AUTOSAR (AUTomotive Open System ARchitecture) is a major industry initiative to manage the growing electrical and electronic complexity in vehicles through the increased reuse and transferability of software modules. Set up in 2003, a worldwide development partnership between vehicle manufacturers, automotive OEMs and other companies from the electronics, semiconductor and software industries, AUTOSAR has been working on the development of open and standardized software architectures for ECUs.
The standard comprises specifications that describe software architecture, application interfaces and a development methodology. The layered software architecture (see figure 1) enables the development of abstracted software components, known as ‘SwComponentTypes’ in AUTOSAR terminology. These software components model car functions and are implemented independently from underlying hardware and can therefore be used across ECUs from different vendors and can also span multiple ECU product generations. The virtual function bus (VFB) is used to assemble and integrate these components into a virtual system and to validate communication consistency between components.
Fig 1 – AUTOSAR methodology system overview
Transformation
Later in the development process, the model is transformed to a network of ECUs, which are interconnected via the CAN, LIN or FlexRay bus, for example. AUTOSAR also defines the methodology and tools required to bring information from the various elements together, including ECU and system-constraint descriptions, to perform this transformation and map software components to a system of ECUs. It also includes the mapping configuration of the ‘basic software’ – running below the AUTOSAR runtime environment – on each of the ECUs. Within the system, there are different domains such as the powertrain for engine control or body control for window/mirror functionality for example, which are connected via network gateways. In essence, it means that a software application developer does not need to be aware of which ECU the application is running on.
Key advantages to the AUTOSAR approach are that all manufacturers and developers have a common idea about what an automotive electrical/electronic system should look like, and have independent software modules and elements that are highly modular, scalable, transferable and reusable. This AUTOSAR model is essentially an abstraction of functionality specifications and can also be used for simulation in the early stages of development to test software and ensure expected behaviour. However, it needs to be considered that it may not be a complete model of the system; and if it is incomplete, then the results of simulation will be likewise.
Timing Behaviour
In model driven development like AUTOSAR, there needs to be a strict separation between the aspects of the model and those of the ECU implementation, especially if there is the future intention to apply the model to a different implementation. The AUTOSAR model is incomplete with respect to formally guaranteeing correctness of timing behaviour. In C code development there is no language construct that enables the modelling of timing behaviour.
This can result in an impact on communication between ECUs: for example, access to automotive environment sensors needs to be done in a scalable, timely and predictable way. Changes in functionality during development will influence timing behaviour, and the complete system will need to be validated repeatedly, significantly increasing system architecture integration effort. In essence, there is no predictable software behaviour and AUTOSAR-compliant tools will need to be used to perform scheduling analysis and timing verification.
A different approach, adopted by Wind River, is to make the design more predictable with regard to timing behaviour. Using an AUTOSAR-compliant tool chain for modelling software components, timing information can be augmented to the software components with the addition of a TDL (Timing Definition Language) construct to the C code design. Due to this time and value determinism is provided, same input values imply corresponding same output values with respect to time which significantly improves reliability. The TDL is based upon the concept of the logical execution time (LET) (see example shown in figure 2), which abstracts the physical execution time on a particular platform and the communication topology and allows the simulation of applications while maintaining real-time behaviour
It means that components can be developed independently providing real abstraction from both the hardware and software platform and the impacts of extended functionality can be seen and dealt with immediately.
Figure 2 – Logical Execution time
The addition of the timing description enables the simulation and testing of the model and the ‘attaching or scattering’ of the software components to the different physical targets without impacting the timing behaviour. This provides the system developer with predictable software integration with the same behaviour on the ECU deployment as seen in the simulation stage.
Enabling the distribution of components across different network nodes without affecting overall system behaviour, OEMs can move to the system architecture stage, either via the federated approach with scattering on multiple ECUs or taking a more consolidated approach to fewer and more highly integrated systems (see figure 3).
Figure 3 – System software consolidated design
Overall, the main advantage of this approach is that timing behaviour is the same in both the simulation and deployment stages, as well as there being no difference in a local or distributed execution of software components on single or multicore ECU designs.
Wind River Automotive Profile
Engineered in conformance with AUTOSAR standards and methodology, Wind River’s Automotive Profile based on VxWorks® industry-leading real-time operating system (RTOS) provides an ISO 26262-certifiable platform and AUTOSAR-compatible run-time environment that supports standardized connectivity and functional interfaces to other automotive software components, enabling simpler, cheaper, and faster interoperability and integration. The VxWorks Automotive Profile enables the reliable consolidation of a large number of software-driven functions on a smaller number of more powerful ECUs.
Figure 4 – Wind River design methodology for automotive
Deploying Wind River development methodology (see figure 4) can enable the smooth transition of legacy systems to multicore ECU systems. Using space/time partitioning, and leveraging logical execution time, OEMs can consolidate multiple vehicle controls with different levels of safety criticality up to ASIL D on to a single hardware platform while maintaining time- and space-based separation and isolation. This introduces the potential for reductions in cost and weight in vehicles and can help mitigate the risk of attack or interference to other software components without compromising vehicle safety or functional performance and enable the growing needs for safe, secure and certifiable software-driven ADAS and autonomous driving applications.
Franz Walkembach is product line manager at Wind River and Andreas Lindenthal is technical director, automotive solutions, at Wind River
