21.2.1 VFB Level

The first level for the definition of an AUTOSAR system is the Functional Model, where SWCs encapsulating sets of system-level functions are connected and cooperate over a VFB (Figure 21.1). Later, they are bound to an execution platform consisting of ECUs connected by communication buses. AUTOSAR components may be defined hierarchically. At the bottom of the hierarchy, components are “atomic,” meaning that each instance is assigned to one ECU (cannot be distributed).

In AUTOSAR, a component defines its required and provided interface through ports, which are the only means to interact with other components. Ports may provide or require access to data or services. A port defining a provided point of access is defined as a P-Port, and a required port is called R-Port. An Interface, attached to each port, may be of type client/server, defining the signatures of the operations that are invoked or provided, or of type sender/receiver, defining a model of the data structures that are written or read. The formal description of the interface is in the software component template, an XML file, which includes the formal specification of the data types and the description of the communication behavior, as specified by attributes.

Those attributes define (among others) the length of the queues for the data ports and the behavior of receivers (blocking, nonblocking, etc.) and senders (send cyclic, etc.). Figure 21.3 shows an example of AUTOSAR components interacting over sender/receiver ports and client/server ports.

The port syntax identifies several types of data ports: regular data type, parameter ports, and nonvolatile ports. Furthermore, the language syntax identifies special ports for the definition of mode switches and also provides for a distinction between application ports and ports that connect application components to AUTOSAR services.

21.2.2 Behavioral Level

In AUTOSAR, the behavior of atomic SWCs is represented by a set of runnable entities (runnables for short) that are in essence entry points of procedures or, as stated in the standardization documents, atomic schedulable units (sequential segments of code, to be executed under the control of a scheduler), communicating with each other over the component ports. AUTOSAR provides several mechanisms for runnables to access the data items in the ports for sender/receiver communication and the services of client/server communication ports. In particular, access to ports of type Send/Receive can be implicit or explicit. In the case of an explicit access, it is the job of the developer to insert calls to the standard RTE API functions for reading from and writing into ports inside the runnables. If a port is accessed in an implicit way by a runnable, then the port contents are copied from the port automatically by the RTE before starting the runnable code (for receive ports) or written at the end of the runnable execution (for sender ports). The activation model, the communication among runnables, and the synchronization in the execution of runnables (local and remote) is specified in a middle-level RTE layer.

21.2.3 RTE Level

The run-time environment (RTE) is the runtime implementation of the VFB. The RTE is local to each ECU. It is a complex layer that must provide location independence in the request of services and data communication among components. The RTE also takes care of the management and forwarding of events to runnables (for triggering their execution or releasing them from wait points). In practice, in the case of local communication, service requests are simply remapped to local function calls. In the case of remote services, the RTE forwards the call to a stub that performs marshalling of parameters in a message, selects the appropriate communication network and the corresponding device driver, transmits the message, and waits for the reply message. When the reply message arrives, the RTE extracts the returned value and closes the remote service request by returning to the caller and generating (if requested) the appropriate event.

The available RTE events are the following:

• Timing Event triggering periodical execution of runnables.

• DataReceivedEvent upon reception of a sender/receiver communication.

• OperationInvokedEvent for the invocation of client/server service.

• DataSendCompleteEvent upon sending a sender/receiver communication.

Each runnable must be associated with at least one RTE event, defining its activation. The scope of each RTE event is limited to the component. For example, two periodic events with the same period activating runnables on different components are not guaranteed to be synchronous. Actually, their relative phase is unspecified unless explicitly modeled by using synchronization components (typically at the BSW level). In case a runnable is activated by more than one event, it must be reentrant or the developer must take care of protecting its internal state variables. A WaitPoint can be used to block a runnable while waiting for an event. Runnables that may block during their execution are called type 2, as opposed to the others, defined as type 1 (this definition impacts the selection of the operating system scheduler and of the scheduling policies). For instance, for an operation defined as part of a component interface, the behavior specifies which runnable is activated as a consequence of the operation invocation event.

The only possible definition of an AUTOSAR MoC emerges from the composition of the behavior options that are attached to each interface and runnable specifications, with no guarantee of consistency. The concept of time and time-related events, which is necessary for the formal definition of an MoC, has only appeared in release 4.0 of the standard. The time model is briefly addressed and discussed in Section 21.2.5.

Finally, there is the description of components/runnables at the implementation level. The language for the description of the internal behavior of runnables is not part of AUTOSAR. AUTOSAR does not require a model-based development flow: a component may be handwritten or generated from a model. For the definition of the models of the runnables, it relies on external tools such as Simulink and ASCET, which brings the issue of the composition of heterogeneous models. The lowest (most concrete) level of description specifies a reference to the code files implementing the runnables of the components and the resource consumption of SWCs. This resource requirements model includes the worst-case execution time of runnables, for which a special section is reserved in the implementation description of the runnables.

AUTOSAR defines the methodology and tool support to build a concrete system of ECUs. This includes the configuration and generation of the runtime environment (RTE) and the BSW (including the real-time operating system) on each ECU. The generation of the RTE and BSW layer is the responsibility of the deployment tools, which define the mapping of the function to the architecture and the generation of code based on the model of the execution platform, defined (in XML format) by the ECU description files.

Finally, the definition and realization of components is not limited to the application level. Designers can define runnables and components at the level of the BSW as well, with less restrictive rules. These runnables and components are included in the code automatically generated by the deployment tools and can be directly activated by events generated at the operating system level (interrupt handlers, counters, and alarms in AUTOSAR).

21.2.4 AUTOSAR Process

AUTOSAR requires a common technical approach for selected steps in the development process, from the system-level configuration to the generation of the executables for each ECU. The AUTOSAR Methodology (a graphical representation is in Figure 21.4) is the description of these activities, with their inputs and outputs. The AUTOSAR Methodology is formally not a true process description since it does not prescribe the order in which the activities should be performed, neither the actors involved.

The first step is the creation of the System Configuration Input, which defines the SWCs, the hardware execution platform, and the system constraints that apply to the mapping of the components onto the ECUs. The format for the formal description is defined in a standard XML schema and includes the following templates.

• Software Components: Each SWC is described in terms of its ports and interfaces, including the data types and the port attributes.

• ECU Resources: Each ECU requires specifications regarding the processor unit(s), the available memory, and the available peripheral devices, including sensors and actuators.

• System Constraints: Regarding the mapping of the signals into bus messages as well as the mapping of the component runnables into tasks and the allocation of tasks into the ECUs.

The System Configuration Input includes or references various constraints. These constraints are very simple and mostly consist of forced or forbidden mapping configurations. In reality, the template allows for the definition of estimates on the availability of resources on ECUs, thereby providing less intuitive constraints to mapping configurations.

The Configure System activity has the responsibility to map all the SWCs to ECUs and also to define the system communication matrix. This matrix describes the message frames exchanged over the system networks, that is, the mapping of the signal information (the data exchanged over ports) into the frames. Deriving such a mapping is extremely complex and consists of a system optimization problem, in which system metrics of interest, including performance and possibly reliability, extensibility, and composability should be maximized considering constraints on resources and timing requirements [4,5]. In the mind of the AUTOSAR developers, this synthesis and optimization process should be assisted by a set of tools, defined as System Configuration. The output of this activity is the System Configuration Description including system information (e.g., bus mapping and topology) and the mapping of SWCs to ECUs.

Further steps must be performed for each ECU in the system. The activity denoted as Extract ECU-Specific Information extracts the information from the System Configuration Description for a specific ECU, thereby generating the ECU Extract of System Configuration. This step is rather simple since it consists of a projection of the elements of the System Configuration Description that are allocated to a specific ECU.

At the ECU level, the system configuration stage is mirrored by the Configure ECU activity, where the RTE and the BSW modules are configured for each ECU. This includes the definition of the task model (the assignment of runnables to tasks) and the configuration of the scheduler and of the BSW components (driver included). The result of the activity is included in the ECU Configuration Description. The configuration is based on the information extracted from the ECU Extract of System Configuration, the definition of the Available SWC Implementations, and the BSW Module Description. The latter contains the vendor-specific information for the ECU configuration.

This activity defines the detailed scheduling information, the configuration of the communication module, the operating system, and other AUTOSAR services. Moreover, this is the time when an implementation must be provided for each atomic SWC. In contrast to the extraction of ECU-specific information, the configuration activity is actually a complex design synthesis and optimization step.

In Build Executable (last step), an executable is generated based on the configuration of the ECU. This step typically involves generating code (e.g., for the RTE and the BSW), compiling code (compiling generated code or compiling SWCs available as source code), and linking everything together into an executable.

Parallel to these steps are several steps performed for every application SWC (to be integrated later into the system), including the generation of the component’s API and the implementation of the component’s functionality.

The initial work in this context starts with providing the necessary parts of the SWC description. That means at least the Component Internal Behavior Description as part of the SWC-related templates has to be filled in. The internal behavior describes the scheduling-relevant aspects of a component, that is, the runnable entities and the events they respond to. Furthermore, the behavior specifies how a component (or more precisely which runnable) responds to events like receiving data elements. However, it does not describe the detailed functional behavior of the component, which is only filled in later, when the Component Implementation (typically the C sources) is provided, together with additional implementation-specific information and information about the further build process steps (e.g., compiler settings, optimizations, etc.).

21.2.5 AUTOSAR Timing Model

Starting from version 4.0, AUTOSAR includes a Specification of Timing Extensions [6]: a language overlaid on top of the existing AUTOSAR concepts with the primary purpose of enabling the definition of timing contracts and the (worst-case) schedulability analysis of the timing behavior of a system. Unfortunately, the keywords “simulation,” “model of computation,” or “model-to-model transformation” never appear among the list of the requirements for the timing model, which is indeed lacking with respect to the needs of a formal semantics for simulation and verification.

With respect to the AUTOSAR process, the timing specification extends the AUTOSAR metamodel, without necessitating a separate template. Also, the extension is introduced without the indication of any additional process steps. Hence, the description of the previous subsection remains fundamentally unchanged.

In the specification of timing extensions for AUTOSAR, the event is the basic entity. It is used to refer to an observable behavior within a system (e.g., the activation of a RunnableEntity and the transmission of a frame) at a point in time. The AUTOSAR timed event is formally derived from a generic abstract concept defined as TimedDescriptionEvent. Unfortunately, timed events are not specializations of RTE events, but define a partly independent structure of timing annotations and constraints. As a consequence, it becomes problematic to maintain and enforce the consistency between the RTE events defining the behavior semantics (i.e., the activation and the synchronization among runnables) and the timed events providing time attributes and constraints that apply to the behaviors. The description of the timing elements follows the organization of the AUTOSAR-level views (Figure 21.5).

Timing events and constraints can be applied to a VFB-level view. Functional end-to-end timing constraints (including possibly the physical sensors and actuators) can be captured in this view. Of course, the VFB view is independent of the platform design and of the allocation of the execution resources. Therefore, the analysis does not include any timing issues from resource scheduling, nor the description of platform overheads. Also, the internal behavior of components is not considered. In conclusion, the constraints that can be defined and analyzed are execution intervals, as opposed to deadlines, defined between events on component ports. As shown in Figure 21.6, the timed events allowed at this level mirror the corresponding RTE events on ports (such as, for example, the time at which data is sent or received, an operation called, or an operation call received). When adding the internal behavior description, timed events can refer to the activation, start, and termination (see Figure 21.7) of the execution of RunnableEntities. This specification still mostly applies to the definition, and possibly verification, of end-to-end deadline constraints.

After the BSW and ECU generation stage, more information is available on the resources of the execution platform, and the allocation of runnables to tasks and of tasks to ECUs. Also, the model now includes the specification of schedulers and the composition of the message frames. Therefore, the events that are defined at these levels also apply to tasks and message frames. This is the level where schedulability analysis can be performed and also the level where timed events could be leveraged to simulate the impact of platform-dependent delays.

In general, at all levels, the occurrence of a timing event can be described by an Event Triggering Constraint. AUTOSAR offers four basic types of event triggering constraints as described in Figure 21.8: periodic events, sporadic events, which are characterized by a minimum interarrival time, and bursty events, in which the specification defines periodic bursts occurring with a given period, and the composition of each burst in terms of number of events and minimum interarrival time. Finally, streams determined by the position in time of each event and fully arbitrary patterns complete the available categories.

In addition, the extension defines constraints and properties that apply to pairs or sets of events (their relations). One notable example of a relation among events is the event chain, with which the concept of end-to-end timing constraint is associated (Figure 21.9).

For the purposes of simulation, an important requirement is the possibility of defining causality dependencies, that is, to enforce a partial order of execution among the system actions and the possibility of enforcing synchronization among the actions. Before the timing extensions, expressing a causal dependency and synchronizing the events triggering the execution of runnables was extremely difficult if even possible at all (an example of this difficulty is provided in the following section dealing with model-to-model transformations).

Unfortunately, the new timing extensions only provide a partial solution. Causality constraints can indeed be expressed by an Execution Order Constraint, which is used to express the functional dependency between ExecutableEntities (runnables) and to restrict their order of execution at runtime. The AUTOSAR Synchronization Timing Constraint, however, is not intended to be used to define a consistent time base for timed events and, in turn, for the system behavior. The definition of a set of system-wide synchronized timed events could have allowed the AUTOSAR modeling of discrete-time systems and the translation of synchronous models in AUTOSAR. However, the original purpose of the specification is different and synchronization constraints do not apply to sets of individual events but to event chains, with the possibility of synchronizing the initial stimulus or the final response times. The motivation for the current definition of timed events is to reduce the pessimism in the worst-case analysis of end-to-end response times. Indeed, the synchronization constraint is intended to be defined together with a tolerance, indicating a true specification constraint on the runtime behavior of complex chains of reactions rather than (for example) a method for enforcing a discrete-time framework.

Another set of constraints can be used for the purpose of synchronization: the offset constraints. These constraints are somewhat more suited to the synchronization of events since they explicitly target individual events rather than chains. However, an offset always refers to a single pair of events (a source and a target), which once again makes its use cumbersome for a system-wide synchronization of reactions.

In conclusion, it is worth noting that version 4.0 of the standard is very recent and still not supported by commercial tools. The hope is that future evolve and become more suited to the goals of simulation and allow for better integration (meaning on formal grounds) of heterogeneous models.

21.2.6 AUTOSAR Tools and the Role of Tools

From the description of the AUTOSAR process, it is very clear how the use of tools is recommended or even mandatory in several activities, such as the code generation and configuration stages. Indeed, there are currently several AUTOSAR tools available on the market. In addition, the AUTOSAR consortium members realized that there is a common or core module that is required by all tool providers. This core module includes the functions for the management of the metamodel and the enforcement of its rules in the construction of a model, the representation of the model in memory, the generation and parsing of the input and output files at each stage of the AUTOSAR process in the standard ARXML format, and basic capabilities for model editing.

The consortium members launched a common initiative to create an open project (Artop, an open source project, although open for contribution and use by the consortium members only [7]) that leverages the metamodeling and modeling features of the Eclipse platform [8] to develop a common foundation that could be exploited by all AUTOSAR tools developers, vendors, and users. The code of the Artop project is available to the members of the consortium that can contribute to its development and use it in the form they see fit, either directly (in the case of OEMs and Tier 1 suppliers) or, more likely, as a common starting point for the development of commercial tools in the case of tool vendors. Artop does not have simulation and analysis capabilities and does not include code generators or the mapping synthesis capability for matching a functional model to an execution platform. These components are intended to be developed as custom extensions by tool vendors.

Currently, tool vendors tend to specialize in the different process activities that are requested by the standard. Several companies offer tools for the design of AUTOSAR models. Examples of products in this area are SystemDesk by dSPACE [9], DaVinci by Vector [10], and AUTOSAR Builder by Geensoft [11]. These tools include RTE generators, but not the configuration of the BSW. Also, they offer (somewhat limited) simulation capabilities (mostly at the VFB and behavior level as discussed in more detail in the following section).

Other companies provide products, such as Tresos from Elektrobit [12], specialized in the stages of BSW generation and configuration, including the operating system.

In general, the mapping of the functional model into the execution platform is quite far from being a synthesis process supported by an optimization engine. Currently, tools typically provide a default configuration of the task model and require a complete user specification with respect to the mapping of the tasks onto the ECUs.

Limited support for AUTOSAR is also offered by other modeling tools, including, for example, Simulink. The support does not include full model-to-model transformation capabilities (not surprisingly, given the sematics distance between the two models), but focuses on these areas:

• Integration of code generated from a Simulink model with the RTE generated by AUTOSAR tools

• Generation of a component or runnable specification by wrapping a ( virtual) Simulink subsystem to allow its inclusion in an AUTOSAR model

• Importing an AUTOSAR component specification into Simulink by

automatically generating an equivalent subsystem interface model

21.3.1 Use of AUTOSAR in the Development Process

A possible use of the AUTOSAR formalism and tools in a development process is therefore the following:

• The system functionality, including the system controls, are modeled in a suitable language (e.g., Simulink), together with the plant model, and validated by simulation with logical execution time assumptions. In case the controller (re)uses AUTOSAR SWCs, possibly imported in Simulink.

• The execution platform for the system is selected and modeled in an AUTOSAR environment.

• The functional model is translated into a corresponding AUTOSAR set of components, some functionality is possibly realized by reusing existing component models, and the virtual AUTOSAR model resulting from the composition is mapped onto the execution architecture according to the AUTOSAR process.

• The result of the mapping stage, performed by the AUTOSAR tools, is the definition of the communication matrix, the task model, and the configuration of the RTE and BSW levels. This definition now allows the simulation of the system functions considering platform-related issues, including the simulation of not only the actual code implementing the application functions but also the code for the communication services and the basic services, with the operating system and the device drivers and the actual network message set.

Although other options are possible, this is a flow that exploits AUTOSAR strengths and attempts to overcome its limitations.

21.3.2 Simulation at the VFB (and Behavior) Level

This is the first option, the one commonly provided by commercial tools and possibly the one without clear advantages with respect to other competing methods since the peculiarity of an AUTOSAR model should be the availability of architecture-specific information, including the tasking and message model and the scheduling information. VFB-level simulation focuses on the higher level of the functional behavior of applications within the context of three layers of abstraction: the interface definition, the behavior definition, and the implementation definition.

For the interface definition layer, the ports and the associated interfaces of a SWC communicating with other components and underlying BSW services are validated and verified. For the behavioral layer, runnables are validated and verified in terms of their execution semantics with respect to their triggering and activation sources. Since there is no model for the RTE and BSW, the events that are relevant for simulation are the set of (simulated) RTE periodic events and the Call and Write events on, respectively, Sender and Receiver ports.

The implementation layer addresses the validation and verification of resource consumption. In particular, if this layer is fully defined, the time when events are generated can be inferred using the worst-case execution time attribute of each runnable. If this information is not available, the runnable execution is simulated to occur in zero logical time [13]. In a VFB-level simulation, the RTE is emulated on the selected simulation platform with its operating system, omitting details about the actual RTE implementation, the task model, and the execution platform.

21.3.3 Simulation at the RTE Level

The next level is the simulation of the system including the set of RTE calls and the RTE overheads. This requires availability of an RTE generator that provides the corresponding code. The simulation at the RTE level adds little to the previous step since it allows to verify the system functions with the actual code that performs the data communication over ports and the generation of events.

21.3.4 Simulation at the BSW Level: From ECU-Level Simulation to Full Architecture Modeling

This final simulation level includes the possibility of modeling components at the BSW level, including the tasking model, the operating system, and the device drivers. Simulation at the BSW level can be performed not only at the ECU level but also at the system level, assuming availability of an architecture model, which allows the emulation of the ECUs and the network. Also, availability of the entire software stack at this point fully enables HIL simulation. This is indeed supported by the dSPACE development toolchain allowing ECU-level HIL simulation on the (micro) autobox platforms.

For the timing evaluation at the ECU level with platform models, there is little support from commercial tools.

An example of performance evaluation of AUTOSAR-based systems applied to a power window case study is described in Ref. [14], where an AUTOSAR application description is translated into a Discrete Event System Specification (DEVS) and then simulated using a DEVS engine. DEVS is a formalism for modeling discrete event systems in a hierarchical and modular way [15,16]. In Ref. [14], a DEVS model of the AUTOSAR BSW layers was used to simulate the real-time characteristics of the power window system. The execution times of all relevant actions were estimated by measurements on a MPC560xP microcontroller running at 64 MHz with an AUTOSAR BSW generated using Tresos AutoCore. The source code was compiled using the MULTI compiler of Green Hills Software. The measures included the execution time of all the runnables for any possible state (without the calls to the RTE); the execution time required for activating or suspending tasks and the context switch times; and the execution time of the writing and receiving of messages in every part of the communication stack including the RTE. The semantics of DEVS is indeed suited for matching the event model of AUTOSAR, and the simulation results were found to be a good match of the observed execution on the actual hardware target. The model included not only the AUTOSAR BSW but also a model of the controller area network (CAN) bus.

Another example of ECU-level modeling effort coupling the description of AUTOSAR SWCs with the BSW generation and an architecture model defined in SystemC is provided in Ref. [17]. As in the previously cited work, the objective is to evaluate the timing behavior of AUTOSAR components taking into account the underlying hardware and communication paths.

In Ref. [17], a formal correspondence was established between AUTOSAR modeling concepts and the corresponding SystemC design concepts [18] at different levels of abstraction (e.g., AUTOSAR runnables map onto SystemC processes). When considering the RTE and the BSW levels, the AUTOSAR design can be translated into a SystemC Programmer View where timing information is provided by timing annotations (in terms of execution cycles). Therefore, if the implementation software exists (e.g., after generation by the RTE generators and BSW configurators), the timing behavior of the software can be evaluated by cycle-level simulation on SystemC models of the hardware platform using the SystemC simulation engine [19].

Additional research works [18,19] discuss simulation options for distributed platforms. In this case, of course, a model of the network adapter and the communication network must be provided. The case of CAN communication is discussed in the models in Ref. [14], and a FlexRay network model is part of the use case showing the applicability of the method proposed in Ref. [17].