AUTOSAR How to deal with non-functional properties Andreas L¨oscher Chemnitz University of Technology [email protected] February 26, 2009 product lines and the possibility to detect errors in early design phases. The AUTOSAR is a partnership of main actors of the automotive manufacture industry. Non-functional properties are those that do not affect the result of an application in terms of the calculated data or the value of a signal. Non-functional properties describe the constraints for the applications. In automotive systems, especially cars, timing is one of the most important properties to ensure the correctness of the system. An example are X-ByWire applications. Other properties are resource consumption and real-time capa1 Introduction bility. This work wants to determine how AUTOSAR handles these requirements. The AUTOSAR1 consortium developed a In section 2 an overview of AUTOSAR standard for software components in au- is given and how a defined software comtomotive systems. This was done because ponent (SWC) is realized on an ECU2 of the growth of complexity in the devel- in the development process. The timing opment of electronic systems. Other goals model of AUTOSAR is shown in section are an improved flexibility for modifica- 3. In section 4 the definition of SWCs is tions, better scalability between different discussed and how non-functional properThe AUTOSAR consortium developed a standard for software components in automotive systems. The goals of this standard is, to enable reusability, scaleability of software components and with this lower costs for the development. Important aspects are non-functional properties such as timing, resource consumption and real-time capability, that must take place in automotive applications. In this paper it is discussed how such properties are defined and how these definitions can be complied. 1 Automotive 2 Electronic Open System Architecture 1 Controll Unit Figure 1: AUTOSAR Architecture (from [1]) ties are described. tive system is build and everything that is needed to integrate different software components in a system of networked 2 Overview of AUTOSAR ECUs. It does not provide information on how the software architecture or the AUTOSAR is both a standard for soft- software components are created. The ware architecture in automotive systems software architecture contains an abstract and the partnership of the participat- communication layer, the methodology ing companies. The AUTOSAR consor- and templates to describe every part of tium was founded in 2003 by the first the system such as the used ECUs, the core members BMW, Bosch, Continental, software components, the communication, DaimlerChrysler, Siemens VDO and Volk- etc. swagen. Till 2004 Citro¨en Automobiles S.A., Ford Motor, General Motors, Peugeot Citro¨en Automobiles S.A. and Toy- 2.1 Virtual Functional Bus ota Motor joined the group as core partners. The current version of the standard All components of a system communicate is 3.1 and was released in 2008. The next over the virtual functional bus (VFB). version is expectet to be realeased in 2009. This is an abstract communication enviIn the current schedule for the introduc- ronment that encapsules the real undertion of AUTOSAR it is announced that lying structure. This means that AUfirst modules will be used in 2010. The TOSAR can be used transparent on diffirst compatible ECUs will be installed in ferent platforms such as FLEXRAY and vehicles in 2011 and the introduction of CAN. The SWCs using the VFB are inAUTOSAR in vehicles will take place in dependent from the used hardware archi2012. tecture which results in more flexibility. The given standard includes a method- It provides the software components with ology that describes how an automo- sender-receiver, server-client communica- 2 tion and error handling. The sender-receiver pattern enables a simple information distribution where data from one sender can be received from several receivers or one receiver can receive information from several senders. The transfer of data is logically atomic. The data-type of each sender-receiver interface is known at configuration time. There are two semantics for this pattern. The ”last-is-best” semantic provides only the newest data. In addition to this, an invalidate service is available. A queued semantic is also available, which delivers all sent data in the correct order (FIFO). In the client-server pattern, the server provides a service and the client uses this service. The client starts the communication by requesting a service. The server waits for incoming requests and provides the service or returns an error if it cannot. ponents on specific ECUs in regards of timing and resources. The output of this process is the System Configuration Description. It contains all system information including bus mapping and topology. With this information, executables for every ECUs are created. Such an executable is the whole software that runs on a specific ECU including the Runtime Environment (RTE), Schedule and the software components. The RTE is the implementation of the VFB on a specific ECU. An illustration of the RTE on an ECU is given in figure 1. There are tools that support the whole process of defining software components and creating an appropriate system. Examples of such tools are ASCET [14] and TargetLink [13]. 3 Timing model 2.2 Methodology The timing model of AUTOSAR is called Generic Timing Framework. This framework is based on events. To define a constraint behaviour like a communication, you have to describe the real behaviour of your system and a model which describes the desired behaviour. The model specifies a guarantee or a requirement. If all requirements are fulfilled, the described components should satisfy the model. The integration process of an AUTOSAR system is described in [5]. This methodology shows how the development process from templates to build system takes place. While this is not a complete description or does define responsibilities or roles, it describes a work-product flow and the dependencies of activities inside of it. An overview of the methodology is shown in figure 2. AUTOSAR provides templates as an information exchange format. Defining a system or a component means filling out these templates. To build a system you must define its hardware and software. In addition to that it is needed that you define all constraints that apply. The idea of AUTOSAR is that powerful tools can create a system that fulfills the defined requirements. This process is called Configure System. It maps the Software Com- 3.1 Events An event occurs at a defined time. In normal case, the event is not directly defined by its occurrence time but by a modeled behaviour of its nature. Let us consider that there is an event OpenDoor. The event can occur multiple times with a distinct occurrence time. AUTOSAR defines two event models which are used to model the occurrence time of events. 3 Figure 2: AUTOSAR Methodology (from [1]) RecurringEvent Model The RecurringEventModel is used to model sporadic events. Its attributes are the highest and lowest inter occurrence time. If tlast is the last time an event occurs, its next occurrence is in the interval of [tlast + tlowestIOT , tlast + thighestIOT ]. If thighestIOT is infinite, you can describe a minimal delay for two events and if tlowestIOT is infinite, you can describe a maximal delay. Figure 3: MaxAge Timing Chain Model provides the possibility to describe more complex behaviour in a construct which PeriodicEvent Model To define periodic is called Timing Chains. Timing Chains events, you have to define a period and a consist of many segments from which evjitter. Periodic events do not have to ocery is associated to an event. There also cur exactly after every period. The jitter exists two models for timing chains. The describes this behaviour. AUTOSAR dedifference between timing chain and model fines it as follows. The period describes is the same as for events. intervals. The time between the beginning of an interval and the occurrence of the related event is called delay. It is required that the difference between the maximal MinMaxOneToOne Model The Timing and the minimal delay has to be smaller Chain satisfies this model if its response time (time between activation of the first than the jitter. and last event in the chain) is between the specified minimum and maximum. The 3.2 Timing Chains timing chain has to be activated once for If you were able to use only single events, each occurrence of the stimulus. This you would be very restricted in the de- model is used to describe event driven sysscription of your component. AUTOSAR tems. 4 MaxAge Model This model has one parameter, the maxage. It is used to describe systems, in which events define changes in the state. In many cases it is not necessary that the system reacts to every event, but that the information provided by a component is new enough. If for each activation of the timing chain, the response time is smaller than maxage, the model is satisfied. Additional to this it is required, that every stimulus leads to an activation, or that a later activation of the timing chain can give a response that is within the deadline (maxage) of the stimulus. For an example see Figure 3. system perspective, an AUTOSAR software component can be mapped on an ECU. The description of the interface of the component can be validated against different models. From an ECU perspective it is necessary to know the resource consumption and the execution time of a component, so that a schedule can be build and the resources like memory can be provided. The full description of software components is described in [3]. This work shows only how resources are described and how the execution time of a component can be specified. The templates provide the possibility to define requirements on other components, functionality, compiler, etc. 3.3 Communication The timing parts of communication on the VFB can now be modeled with the timing framework by using Timing Chains. The sender-receiver communication defines two elements for this. The DataElementAvailableonPPort and the DataElementAvailableonRPort event. The difference between these events describes the duration of the communication. The AUTOSAR provides in its templates attributes to specify requirements on the response time. Other attributes, which are considered as further extension of the VFB communication attributes are guarantees as well as requirements for period, jitter and inter occurrence time. The server-client communication pattern can be described in a similar way. 4.1 Resource Consumption The resources of a software component are represented in memory. This can be divided into static allocated memory on implementation and dynamic allocated memory on runtime. The description of statically allocated memory is simple. AUTOSAR allows this for every implementation of a software component and chooses the right one for the mapping. The description of dynamic allocated memory is more difficult. AUTOSAR divides stack and heap memory usage. The stack is used to store temporary data like parameters or local variables. This means that the stack usage is dependent on the depth of the calling hierarchy. AUTOSAR provides some methods to describe the used stack. These methods are WorstCaseStackUsage, MeasuredStackUsage and RoughEstimatedStackUsage. The first is determined analytically. The second one interferes from measures with test patterns. A maximum and a minimum amount of used stack can be defined. The last one is a rough es- 4 Software Components Description Of prime importance is the definition of the behaviour of the software components. This must be done by describing the internal and external specifications. From a 5 Figure 4: AUTOSAR ECU software architecture (from [1]) time, simulated execution time, measured execution time and rough estimated execution time, which work like definitions for the memory usage. Because of the dependency from other specifications, you can describe the context, in which the execution time was achieved. timation. The second type of dynamic allocated memory is heap memory. This describes memory which is explicitly allocated. AUTOSAR provides the same methods to describe the used memory. One problem of heap memory is, that the available memory could be segmented unpropitiously. This means, that even if enough memory is available, it is not accessible. Heap memory as well as stack memory should be used with caution. 5 System Description AUTOSAR provides a template for the system description. Describing the system means filling out the template. The template contains information components of the system and the relations amongst them. This includes hardware and software. Constraints related to communication and mapping can also be described. AUTOSAR supports redundancy at this point. There can be made many con- 4.2 Execution Time The execution time of a software component depends on many different properties of the system. For example the used ECU, the chosen implementation of the software components and the context the component is used. The execution time can be defined as worst case execution 6 straints for redundant components. the system description. The possibilities given here are similar to that of the mapping constraints. Mapping Constraints A fundamental It is possible to define permissible and concept of AUTOSAR is, that SWCs can forbidden communication paths. In adbe developed independently from the used dition to this you can define common ECU hardware. The assignment of comand separate signalpath. These definiponents to ECUs is called mapping. Nevtions describe two or more communicaerless, there may be some SWCs that are tions. Common signalpaths describe sigalready mapped in an earlier phase of the nals that must use the same physical path. system generation process, or other conThe opposite is the separate signalpath. It straints, that must be respected. defines that two or more signals must not AUTOSAR allows to force the mapping take the same physical way. This should of SWCs on ECUs. This can be described be used for redundant communication. in the System Mapping description which is part of the System description. If a specific implementation should be used, it can RTE Resource Estimation An AUbe forced at the same place. A SWC can TOSAR SWC uses the services of the RTE be mapped manually with these specifica- which must be mapped on the ECUs additions. In addition to this it is possible to tionally to the SWCs. Therefor it is necdefine a set of ECUs a SWC must or must essary to describe the resources the RTE needs on every ECU. This is done like it is not be mapped on. A more dynamic definition of con- described in here 4. These specifications straints is the possibility to define clus- are also part of the system description. tered or separated components. Separated components are such, that must not be mapped on the same ECU. This is im- 6 Review and Evaluation portant do ensure that redundant comAUTOSAR provides the possibility to deponents do not fail if the hardware fails. scribe software components and timing The opposite of separated components are behaviour. The discussed question is, clustered components. These must be if the capabilities of description provides mapped on the same ECU. Sometimes it enough information for the design process is important that two or more components of an automotive system in respect to nonare mapped on one ECU to ensure correct functional properties. AUTOSAR gains behaviour. This could be the case if these flexibility and abstraction for the design two components need a fast communicaprocess of software components. It protion. vides a standardized API and interface descriptions so that software components Communication Constraints While the can be exchanged in ways programmers system configuration process, the actual know from Java or C++. The key goals signals between ECUs are calculated. At while developing the standard where not this point it happens that different com- to solve timing problems or other critical munication paths are possible. AU- requirements. The goal was to support inTOSAR allows to specify constraints ac- tegration of software-engineering perspeccording to the communication as part of tive. 7 7 Conclusion The timing model does provide only basic features. There is no possibility to model the timing behaviour of the communication together with the scheduling behaviour. AUTOSAR provides no support for a systematical timing analysis procedure. Not being able doing so, its hard to prove that a built system will work in practise. The templates for describing software components do not provide the possibility to define shared resources. The ussage of shared resources can result in longer execution times which means, that the build schedule may not been correct. AUTOSAR provides a powerful methodology to develop software components for automotive systems. It describe the integration process of software components with respect to scalability, complexity and reliability. It does not provide information about how it should be done in detail, but how the components of a system have to be described so that an successful build process on a specific platform is possible following the methodology. AUTOSAR at the current stage do not provide a proper timing framework. The existing timing framework which is described in [1] is not yet part of the standard and lacks many features which are crucial for the system build process. There are solutions available to this problem. The first would be to define a proper timing framework for AUTOSAR. The need of such a framework has been recognized by the consortium and the standard will be extended further releases. [9] describes a way to extend the given standard with an additional timing framework which is not part of the standard but that provides the missed features. A model for extending AUTOSAR with a more proper timing framework is described in [9]. The TIMMO project is an industry driven complement of AUTOSAR which contains MARTE as Timing Augmented Description Language (TADL). The timing behaviour is described by MARTE which provides many of the features missed in AUTOSAR including a systematical timing analysis procedure on model level. There is also the possibility to describe shared resources and timing behaviour of communications in respect to the schedule of the software components. References In [6] the AUTOSAR consortium pointed high reliability and other safety parameters as one main objective of the standard. The usage of redundancy to reach this objectives are also described in this document. AUTOSAR fullfills this objectives by providing support for redundant components. Various constraints related to this can be specified in the system definition like separated mapping or separated communication paths. This however must be done manually. AUTOSAR itself do not provide an automatism for this. [1] Technical overview 2.2.2. Technical report, AUTOSAR GbR, 2008. [2] Specification of the virtual functional bus 1.0.2. Technical report, AUTOSAR GbR, 2008. [3] Software component template 3.1.0. Technical report, AUTOSAR GbR, 2008. [4] Specification of bsw module description template 1.1.0. Technical report, AUTOSAR GbR, 2008. 8 [5] Autosar methodology 1.2.2. Technical report, AUTOSAR GbR, 2008. 2006. Second International Symposium on, pages 9–10, Nov. 2006. Targetlink product in[6] Autosar main requirements 2.0.5. [13] dSPACE. formation, January 2009. http:// Technical report, AUTOSAR GbR, www.dspace.de/ww/de/gmb/home/ 2008. products/sw/pcgs/targetli.cfm. [7] Specification of the system template Ascet product infor3.0.4. Technical report, AUTOSAR [14] ETAS. mation, January 2009. http: GbR, 2008. //www.etas.com/de/products/ [8] H. Heinecke, W. Damm, ascet_software_products.php. B. Josko, A. Metzner, H. Kopetz, A. Sangiovanni-Vincentelli, and M. Di Natale. Software components for reliable automotive systems. Design, Automation and Test in Europe, 2008. DATE ’08, pages 549–554, March 2008. [9] S. G´erard. H. Espinoza, K. Richter. Evaluating marte in an industrydriven environment: Timmo’s challenges for autosar timing modeling. Design, Automation and Test in Europe, 2008. DATE ’08, March 2008. [10] Marco Di Natale. Virtual platforms and timing analysis: status, challenges and future directions. In DAC ’07: Proceedings of the 44th annual conference on Design automation, pages 551–555, New York, NY, USA, 2007. ACM. [11] P.-E. Hladik, A.-M. Deplanche, S. Faucou, and Y. Trinquet. Adequacy between autosar os specification and real-time scheduling theory. Industrial Embedded Systems, 2007. SIES ’07. International Symposium on, pages 225–233, July 2007. [12] K. Richter. The autosar timing model – status and challenges –. Leveraging Applications of Formal Methods, Verification and Validation, 2006. ISoLA 9