AUTOSAR proof-tests vehicle electrical design at every level

·         Software component simulation

Individual software components, each representing a function or a subset thereof, must be developed and verified before they can be delivered to the more advanced simulation stages. The SWC that emerges from this step is proven to adhere to the AUTOSAR interface specification, including its ports and OEM interfaces.

While the SWC is the smallest discrete component that can be manipulated as a unit within the ECU, the SWC itself is in turn made up of code elements known as “Runnables.”

The Tier 1 supplier’s task is to implement the desired behavior; that is, to make the SWC live up to the design intent. Either manual coding or automatic code generation can be used to achieve this result.

·         ECU simulation

The input for the ECU simulation normally consists of the extracted ECU configuration which is generated by an AUTOSAR authoring tool such as Mentor Graphics Volcano™ Vehicle Systems Architect (VSA). The ECU configuration contains all of the information items assigned to a specific ECU. This includes the ECU software composition that describes the overall functional behavior of the ECU. Depending on the desired configuration, this will involve simulation starting with an initial high level of abstraction (for software architecture validation) and proceeding down to detailed execution.

·         Software architecture simulation

In this phase, all software components are assembled into the top-level composition. The simulation in this step addresses the software architecture and the overall behavior of the logic architecture. By this means the interaction of software components coming from diverse suppliers can be “virtually” integrated and verified.

Consistency checks and design rule checks

In contrast to the dynamic simulations just summarized, consistency checks are static analyses applied at key points in each phase of the design flow.

Consistency checks begin early in the development process. In a consistency check, a design’s compliance with its specified parameters is monitored, as are the design rules that apply.

Consistency checks can also verify name conventions as well as the validity and completeness of parameters. A typical consistency check might be expressed as follows:

“Port connection X not valid because of the incompatible data
elements of the connected sender/receiver interfaces”

DRCs (Design Rule Checks) are usually design-specific and user-defined. A DRC literally monitors adherence to recorded rules such as:

“Function X must be available twice on the control unit Y to ensure redundancy”

To execute DRCs a tool must be equipped with an open interface that allows user-specific rules to be formulated according to a rule description language such as OCL (Object Constraints Language). A prerequisite for DRC checking is, of course, access to all objects, parameters, and relationships defined in the AUTOSAR meta-model.

Double-click reveals errors’ hidden causes

A dedicated "Problems View" in the AUTOSAR Authoring Tool VSA (Vehicle Systems Architect) displays the result of a series of consistency checks. Double-clicking on an error message causes the cursor to jump directly to the cause of the problem in the AUTOSAR Editor, allowing the cause of the problem to be spotted easily.

A consistent design forms the basic prerequisite for a simulation, because the quality of the input parameters ultimately determines the feasibility and quality of the simulation. The number of the parameters to be specified depends largely on the abstraction level to be simulated. AUTOSAR defines two abstraction levels:

·         The Virtual Function Bus (VFB) and…

·         The Runtime Environment (RTE)

These two abstraction levels form the foundation for AUTOSAR simulations that will be performed subsequently.

Figure 2 illustrates the VFB level. The Virtual Function Bus defined by AUTOSAR is a representation of the communication management among SWCs. The data exchange between the SWCs takes place via data elements, based on the sender/receiver or client/server communication. It must be noted here that within the VFB level, no communication passes to the Basic Software (BSW) layer, which is hierarchically below the RTE. This has been defined deliberately to ensure a clear separation between hardware and software, and it provides an abstraction to a purely functional presentation. The timing is determined by the time constants of the RTE Events that trigger the executables. The VFB abstraction level is an efficient means to verify the functional behavior of the software architecture early in the development process, which helps the engineer detect and correct design problems early, when the cost of doing so is lowest.