1 AUTOSAR Seminar WS2008/ Assignment: Simulation of Automotive Systems in the Context of AUTOSAR Krasnogolowy, Alexander March 31, 2009 Hasso-Plattner-Institut for IT-Systems Engineering University of Potsdam Prof.-Dr.-Helmert-Straße Potsdam Department Systems Analysis and Modeling Prof. Dr. Holger Giese Abstract. In the automobile industry, the usage of embedded systems becomes more and more important. Today, many innovations are realized by software solutions. The increasing complexity on the one hand and the high performance requirements on the other hand, leads to a new challenge in assuring the quality of this systems. This paper takes this problem into account and shows how the quality objectives of automotive systems can be assured with the help of simulation techniques in every development stage. For this purpose, the development stages are introduced and it is shown which kind of simulation can be used in which stage. Furthermore, the usage of AUTOSAR leads to new possibilities in simulating automotive systems. Through the hardware independent software architecture, applications can be already simulated in an early development stage. Tools supporting such a simulation are presented and discussed.
2 2 Introduction 1 Introduction Simulation is the transformation of a system to a model and conducting experiments with that model  to analyze the dynamic behavior . The model of the system can be a model of an an existing system (descriptive model) or a system, which is has to be build (prescriptive model). If the system is simple, it can be transformed for example to a mathematical model and the given problem can be solved analytically . However, real world system are usually very complex and analytical analyses are difficult, because the software consists of many lines of code and is interacting with other components. Embedded system are also influenced by the scheduler of the underlying operating system and also interrupts, which can occur randomly. Moreover, an application has many different execution paths and states, which have to be investigated. So, because of the high complexity and the different combinations in the control flow of the embedded system a simulation is executed. In a simulation only the most interesting cases are considered and for every simulation step one possible execution path is gone to observe the behavior of the system . It is possible to analyze the timing behavior, the memory usage and to check the logical behavior of the software. To see if the behavior of the system is correct, it can be tested on the real embedded system with its real environment, but this is very expensive and assumes the availability of the real system. However, in an early stage of the development, the real system is usually not available. Therefore the simulation is done at a high level for example on a workstation, which emulates the developed software and the environment, which makes a simulation and also changes of the embedded system very easy and cheap  because no special hardware is needed. Moreover, if the simulation is done in an early stage, less redesign must be done in late development stages, which increases the design productivity. This assignment is structured as follows. In the first part, a short introduction into the development process of automotive software systems (and embedded systems in general) is given which is generally based on the V-model. These foundations are used afterwards to show in which stages simulation is involved and which kinds of simulation exist. For this purpose, Model-in-the-Loop, Software-in-the-Loop and Hardware-in-the-Loop Simulationes are introduced. After the theoretical part of this assignment, the next part describes how a simulation with the help of tools can be done in practice, if the existing software architecture is based on the AUTOSAR Standard. A tool and an extension of MATLAB/Simulink developed by dspace  is introduced, the differences are explained and the relationship between them is discussed. Afterwards, also a short overview about a tool from the bachelorproject 2007/2008 about the performance evaluation of AUTOSAR architectures is given and compared with the solutions of dspace. Finally, the differences between the simulation of AU- TOSAR based system compared to the traditional systems is summarized.
3 Simulation in the Development Process 3 2 Simulation in the Development Process 2.1 Development Process of Embedded Software Systems To structure the process of developing software systems, many different process models are available. These are for example the waterfall model, the Rational Unified Process or the Extreme Programming. Another one is the V-model  which is very suitable for the development of embedded systems, because it focuses on quality assurance aspects which is given by the formal procedure, the creation of intermediate results and test activities on the different development stages. The V-model consists of a number of phases. On the left hand you have the requirements analysis, system design, architecture and module design and at last the implementation. For every step, a test activity on the right hand is specified. These are unit testing, integration testing, system testing and user acceptance testing. In addition to this, a system is usually developed in a sequence of intermediate product-appearances. The first appearance is the model, which is iterative developed. This means that first, low level requirements are established, detailed model design decisions are made and after that validated through model checking, state transition and model integration tests and of course a simulation of the model (see section 2.1.1). The resulting model should reflect an abstract view of the system, which emulates the required system behavior. The process of developing an AUTOSAR based system is described in the AUTOSAR Methodology. It is not a complete process description but defines dependencies of activities on work-products. For example it illustrates design steps from the system configuration until the generation of an ECU executable. This includes among other things that software components and the hardware have to be modeled, implemented, selected and mapped to ECU. A detailed overview about this methodology can be read in assignment. Tools supporting the development with AUTOSAR are introduced in section 3. The next step in the development process is the automatically generation of code from this model. The code is embedded in an experimental hardware - the prototype. In the same manner as the model, the prototype is developed in its own V-development cycle. This means that on the right hand side we have activities like unit test, software integration and acceptance test, a system integration test and a simulation, too. The automatically code generation with different tools is also shown in section 3. The last step is the replacement of the experimental hardware with the real one - the final product. For the final product, production requirements and detailed design decisions are made whereas on the right side of the V-model the system is tested, certificated and release criteria are checked. These three product-appearances (model, prototype and final product) leads to the so-called multiple V-model (see figure 1). The advantage of this separation is that it is cheaper and quicker to change a prototype or a model than to change the final product . Moreover, if the model is validated to be correct, you just need to
4 4 Simulation in the Development Process Fig. 1: Multiple V-model test the prototype against the model and do not need to start the development from the beginning. However, the multiple V-model does not consider the fact that a complex system is not developed as one piece but split into smaller components which are developed separately. This development principle is one of the main aspects in AUTOSAR where a system is developed in seperate Software Components. This decomposition is usually done on the left side of the V-model in the design phase where it is determined which components should perform which task. Later, in the system integration stage the components are recomposed to a whole system. This principle, that a system is divided into components which can be divided into sub-components, sub-sub-components and so on where each component is developed in a separate V-development life cycle, is called the nested multiple V-Model . In every stage of the multiple V-model (model, prototype, final product) a simulation of the intermediate product is done. For that, special simulation and test methods are used. These are the Model-in-the-Loop Simulation and Rapid Prototyping in the model stage, the Software- and Hardware-in-the-Loop Simulation in the prototyping stage and the final product is tested by a system test in the last stage Model-in-the-Loop Simulation and Rapid Prototyping After the requirements for the system are specified, the functional specification is done, which can be tested by a Model-in-the-Loop (MiL) simulation . Therefore, the functional specification must result in an executable model - the simulation model. The goals of simulating the model are to prove the concept of the design, to optimize it and to develop and verify requirements for the next development step (prototyping). Testing and simulation in the model stage is usually done in the following steps: one-way simulation, feedback simulation and rapid prototyping .
5 Simulation in the Development Process 5 (a) One-way simulation (b) Feedback Simulation Fig. 2: Simulation types The one-way simulation means that input signals are generated manually or by a tool and fed into the simulation model. The algorithms described by the model are applied to the input and an output is generated which is recorded and analyzed (see figure 2(a)). However, there is no dynamic interaction between the plant and the simulation model. The next step is the feedback simulation. This kind of simulation is more complex than the one-way simulation because a second model is used - the plant model. Instead of just generating signals and recording the output, the plant model behaves more dynamically. It prepares the input signals for the model of the embedded system creating an output which is fed back into the plant model resulting in a new input for the embedded system (see figure 2(b)) . Such a plant model consist, among other things, of the motor, vehicle dynamics and the environment . An example for one-way simulation as well as the feedback simulation will be shown in section 3. If the feedback simulation was successful and the real environment is available, the plant model can be replaced with the actual plant or a close equivalent . A computer is connected to the sensor and actuators of the car and the model of the embedded system is executed. The computer transfers the output signals from the model to the actuators and the signals from the sensors of the car to the model. This is called rapid prototyping which offers a fast and early detection of errors in the specification and concept  Software-in-the-loop Simulation The Software-in-the-loop Simulation (SiL) is quite similar to the the MiL Simulation with the difference that not the model of the embedded system is executed, but the code, which is generated from that model. To execute the code, the code must be compiled first for a target processor. This can be the processor of the
6 6 Tools for Simulation of AUTOSAR host PC or the processor of the embedded system. In the first case, the software would run in an environment which is not restricted in resources and performance (a PC is usually much faster than an embedded system). The goal of this test is to verify the behavior and validate the simulation model from the model stage . In the other case that the code is compiled for the processor of the embedded system, it can be executed on the host PC running in an emulator. The goal of this test is the verification of the correct execution on the target processor with restrictions on bit width and other processor specific limitations Hardware-in-the-Loop Simulation The Hardware-in-the-Loop Simulation takes place in the prototyping stage. The difference to the SiL Simulation is that the test environment is not a PC or an emulator but it is a hardware part where the software is loaded . First, the hardware part is just an experimental board, which contains the real target processor and memory but has only simple signal generators and an oscilloscope monitors the output of the embedded system. If the whole plant is still simulated by the PC and just the code is executed on the real target processor then it is also named a Processor-in-the-Loop Simulation . Later, the experimental board is replaced by a prototype, which is nearly equivalent to the real system and is connected to hardware components of the car. With that, the embedded system can be simulated together with its surrounding hardware. 3 Tools for Simulation of AUTOSAR In this section it is shown which tools are used in the above mentioned stages of the development life cycle process in the context of AUTSOSAR and which kind of simulations are supported by this tools. After introducing them, a brief comparison of the features is given. 3.1 MATLAB / Simulink / TargetLink MATLAB is a tool by MathWorks, which allows to solve technical computing problems. It offers an add-on based environment to solve particular classes of problems . One of this add-ons is called Simulink, which provides an interactive graphical environment for a Model-Based-Design and simulation of embedded systems. To model and simulate AUTOSAR based systems the add-on TargetLink is needed which is a tool by dspace providing an AUTOSAR blockset and a code generator. Modeling with TargetLink focuses on the application layer of the AUTOSAR architecture (for more information see assignment from ). It is possible to model AUTOSAR compliant SWCs and analyze their behavior on the host PC (MiL or SiL Simulation) or on an evaluation board (PiL). The code which is generated can be used for the target ECU . The usage of TargetLink primarily takes place in a very early development stage of the multiple V-development cycle. After the requirements were verified, the developer can start with the functional specification of the embedded system.
7 Tools for Simulation of AUTOSAR 7 Fig. 3: TargetLink AUTOSAR blockset To create a model, the blocks of the AUTOSAR blockset (see figure 3) and some certain blocks of Simulink can be used. Fig. 4: Example of the inner view of a SWC Principles of Modeling with TargetLink AUTOSAR compliant SWCs can be modeled as TargetLink subsystems. However, they are not the same as SWC. Modeling software components with TargetLink basically means modeling a software component s runnables and specifying each runnable s communication. . This means that a subsystem in TargetLink is not just a container for Runnables like a SWC, but rather how
8 8 Tools for Simulation of AUTOSAR the Runnables are connected to each other. In anyway, the subsystems can be structured in a way that every subsystem corresponds to a SWC. However, it is not possible to nest subsystems into another one and so it is not possible to model AUTOSAR composition components. For communication with Runnables of other subsystems SWC In- and Outports of the AUTOSAR Blockset can be used. An example of a modeled SWC in TargetLink is shown in figure 4. There you can see how the Receiver Port of the SWC is connected to the Runnables and how the Runnables communicate among each other. Moreover, you can see that the subsystem gets two inputs, but has only one SWC input port. If a MiL simulation is done all ports would be used, but if code for the SWC is generated only the SWC input port is considered, because only this port is an AUTOSAR port. Fig. 5: Example for a Runnable which computes the sine of a value To model an AUTOSAR compliant Runnable, the developer has to model a subsystem which describes the functional behavior of that Runnable and contains the Runnable-block (see figure 5). The AUTOSAR standard specifies that Runnables are triggered by RTE- Events (see assignment ). This property can be set for a Runnables in TargetLink but is not regarded in the simulation. The execution of a Runnable is only based on the data-flow or a function-call-trigger. So, it is possible to simulate such RTE Events by modeling them manually as a stateflow . An example is shown in figure 6, where the controller subsystem gets the RTE Events from a stateflow (left side) as an input which are redirected to the runnables (see figure 4). The communication between Runnables can be modeled with the In- and Outport blocks of the AUTOSAR blockset. They can be used to transfer data elements, operation arguments and interrunnable variables. Runnables can provide operations, which are triggered by an OPERATION - INVOKED EVENT RTE event. For that, they have to act as a server. A server Runnable, for example, consist of an inport block, the operation block and an outport block (see figure 5). To call this server, the client must uses the Client Port block which transfers the arguments to the Runnable and get the results from it.
9 Tools for Simulation of AUTOSAR Simulation with Simulink / TargetLink Fig. 6: MiL Simulation TargetLink supports three modes of simulation: MiL, SiL and PiL. The MAT- LAB/Simulink engine is used to simulate TargetLink models. Because of this, TargetLink blocks are just enhanced Simulink blocks with code production properties. A typical MiL scenario with a Feedback Simulation is shown in figure 6. On the left side we have a reference signal which generates an input for the model of the embedded system. The calculated results are fed into the plant resulting in a new input for the model of the embedded system. To observe the behavior of the system, a so-called sink (right side) is appended to the system which generates a graphical output of certain values during the simulation. Such an output is shown in figure 7. After the behavior of the system in the MiL simulation is verified, the simulation type can be changed to a SiL simulation, which takes place in the prototyping stage. To be able to execute a SiL simulation, code must be generated first from the model. The code which is generated is an AUTOSAR compliant C code, one the one hand the code of the SWCs is generated and on the other hand the code of the RTE. Because you cannot define any deployment of SWC to ECUs, the behavior of the RTE is just as it is executed on one ECU. However, the code of the SWC can be used for example in SystemDesk which can generate ECU-specific RTE code which is illustrated in the next section. For any other non-autosar elements in the model like the signal generator in figure 6 or the sink, no production code is generated. If the SiL is in progress, also non- AUTOSAR elements are executed from the simulation engine as it was done in the MiL simulation. For more information how the data is transfered between non-autosar blocks, generated code and the simulation engine see . Because the SiL Simulation takes fixed-point effects into account (in opposite to the MiL simulation) the simulation results can differ from the MiL results. In
10 10 Tools for Simulation of AUTOSAR Fig. 7: Output from a MiL Simulation Fig. 8: Calculation of a sine curve in MiL and SiL with wrong dimensioned data types in the code
11 Tools for Simulation of AUTOSAR 11 figure 8 a sine curve is computed in the MiL and SiL mode. Because the data type in the model had no restrictions (32 bit floating point) but was just an 8 bit integer (restrictions of embedded system) in the generated code, such big differences can occur. To check wheather the generated code also works on the real hardware, the simulation mode can be changed to PiL mode. In this mode, the target processor specific compiler must be chosen. After the code is generated and compiled, it must be downloaded to the evaluation board. Now, the system can be simulated with hardware specific effects like limited stack size, bit width and performance restrictions. 3.3 SystemDesk SystemDesk by dspace is a tool supporting the development of distributed automotive electrics/electronics systems according to the AUTOSAR approach. . In the multiple V-development cycle it can be attached to the modeling stage as well as the prototyping stage. One the one hand, you can use SystemDesk to model the software architecture with AUTOSAR Software Components including Runnables and Ports but also to model the hardware topology with the ECUs and the network communication with busses. These modeling activities taking place in the modeling stage. On the other hand, you can also use SystemDesk to generate C code and based on that, execute a SiL, simulation which is done in the prototyping stage. For more information about how to model in SystemDesk, see assignment . This section just focuses on simulation possibilities in SystemDesk and how models can be interchanged with TargetLink Simulation in SystemDesk SystemDesk provides a feature for a non-real time SiL simulation. The simulation is based on the C code of the SWCs and the RTE. The C code for the SWCs can be token from the production code generation of TargetLink. The code for the RTE is generated by SystemDesk depending on the deployment of SWCs to ECUs and the ECU configuration. SystemDesk uses a C compiler which generates Windows DLLs for the simulation engine. SystemDesk supports one-way simulations as well as feedback simulations. For the one-way simulation you can use stimulus generators or replay recorded data from a previous simulation. The feedback simulation requires a model of the plant, which can be importeted from a Simulink model. The documentation of SystemDesk gives some important properties for the simulation process. The simulation is executed in virtual simulation time, which means that the time passes faster or slower on the host pc compared to the time on the target processor. However, it is possible to slow down/speed up the simulation clock to approximate the real time. The scheduling, which is based on the configuration of the operating system is considered, which means that the correct order of tasks and runnable calls are simulated.
12 12 Tools for Simulation of AUTOSAR SystemDesk makes a Zero time assumption, which means that tasks are executed instantly in virtual simulation time. From this, it follows that it is not possible to detect time critical effects, for example if a deadline is met or not. SystemDesk provides a simulation at different verification stages which are described in . These are the logical level verification, system level verification and the implementation verification. On the logical level the Virtual Functional Bus Concept(VFB) defined by AUTOSAR is used. The VFB concept states that SWC are implemented independently from the underlying hardware (at this stage, the hardware topology in SystemDesk is not specified). The VFB is a communication mechanism where the SWC can exchange data, not knowing weather the data transfer happens on the same ECU or to another one over a bus. More information about the VFB concept can be read in assignment . SystemDesk provides a simulation of the VFB, which requires the architecture of the SWC, the internal functional behavior and the connection between the SWC. All SWCs are automatically mapped to one ECU which is called the Virtual Processor Unit (VPU). Runnables are usually activated by Tasks, however, because there is no OS configuration available in the logical level verification stage, a default scheduling is computed by SystemDesk. This looks like the following: Cyclic Runnables are mapped to a cyclic task and another task takes care of acyclic Runnables which are triggered by RTE Events. If the development proceeds and the information about ECUs as well as the buses are available and configured in SystemDesk, further effects can be simulated in the so-called system level verification stage. The properties of this stage are that the SWCs have been mapped to ECUs and more details of SWC are defined. SystemDesk provides a feature to simulate the effects of the busses. For a CAN Bus the simulation can take into account the arbitration and the bus capacities. So it is possible to simulate the bus usage as well as the communication delays. If the production code and the production ECUs are known, a more detailed simulation can be executed in the so-called implementation verification stage. The timing of the application is determined by the underlying operating system, which considers scheduling effects. To simulate this scheduling effects, SystemDesk uses an AUTOSAR compliant operating system, which simulates the correct execution order of task and Runnable calls. However, the execution time is usually faster on the host pc than on the target hardware. To get better results which are more realistic, it is possible to slow down the SystemDesk clock. An example of a simulation result is shown in figure 9(a) and 9(b). Both figures show a measurements of two different variables. The rectangular signal is created by the Plant SWC and the other signal shows the calculated variable of a Controller SWC. In figure 9(a) both SWCs are deployed to one ECU. It can be seen that the controller responds immediately if the edge of the plant is rising. In opposite to figure 9(b) where the SWCs are deployed to another
13 Tools for Simulation of AUTOSAR 13 (a) Simulation with one ECU (b) Simulation with two ECUs Fig. 9: Simulation results in SystemDesk ECU (which are connected over a bus). Such a reconfiguration can be done very easily in SystemDesk. It can be seen that the controller responds delayed because the signal of the plant needs some time to be transferred over the bus. So, it is possible to try different configurations of the system in SystemDesk and to check what are the effects. This possibility is a very important advantage of AUTOSAR based system Relationship between SystemDesk and TargetLink Both tools can be used in an early development stage as well as in the prototyping stage where code is generated and afterwards simulated. The order, in which the tools are used in the development process, can be different. On the one hand, it would be possible to model the software architecture first in SystemDesk and then the functional behavior in TargetLink, which generates code that is used for the implementation of the SWC in SystemDesk. On the other hand, it is also possible to define the functional behavior first in TargetLink and then the software architecture in SystemDesk. Finally, both tools can be used in parallel to design an automotive system. TargetLink has a feature which is called Data Dictionary (DD). The DD is a container that holds all relevant information about an ECU application . This includes tasks, variables but also AUTOSAR SWCs. Figure 10 shows a diagram where you can see which tools are connected to the DD and which
14 14 Tools for Simulation of AUTOSAR Fig. 10: Data Dictionary formats are supoorted to export and import the data. If for example a subsystem in TargetLink is modeled, a SWC can be created in the DD to reference that this subsystems is mapped to a SWC. This can also be done with the Runnables, and their ports. The advantage of that DD is that the data is kept consistent for example between the TargetLink model and the AUTOSAR model. If one is changed, the other one is changed too. Moreover, it is possible to export the AUTOSAR model as an XML file and to load this XML into SystemDesk. A use case is, for example, that you first create your software architecture in SystemDesk, export this to XML and importing it into the DD. Afterwards, the DD objects are mapped to TargetLink objects for example a SWC to a subsystem and so on. And the development of the functional behavior of the SWC can start at this point and doesn t need to modeled again. SystemDesk also offers a possibility to integrate Simulink models as atomic software components . 3.4 Bachelorproject 2007/2008 In the bachelorproject 2007/2008, a concept was developed how a simulation of an AUTOSAR modeled system can be done. For this purpose, the exisiting simulation tool chronsim was used, which was based on a task model and a model for describing the hardware architecture (with busses), the deployment and real time requirements. The goal was to define a transformation from an AUTOSAR system to the traditional system with that a simulation can be executed. In addition, real-time requirements were defined in the AUTOSAR model which are considered in the evaluation of the simulation results.
15 Summary of the Differences in the Simulation of traditional and AUTOSAR based Systems 15 For the simulation, the code of the tasks is compiled by chronsim and executed on the simulated target hardware. It can be characterized as a SiL simulation with similarities to a HiL simulation, because of the strong consideration of hardware aspects during the simulation. 4 Summary of the Differences in the Simulation of traditional and AUTOSAR based Systems In section 2 of this assignment, the process of the development of automotive software systems in general including the simulation of such systems was illustrated. In section 3 it was shown, which tools are available to simulate AUTOSAR based systems. This section should give a small summary about the benefit of using AUTOSAR to simulate systems and what are the differences to the traditional methods. Today, many innovations in a car are realized through softwre. The increasing complexity as well as the growing size of the systems leads to an outsourcing of the functionality to automotive suppliers. The suppliers develope their components in their own life cycle and use their own tools. In the past, the result was that every supplier had their own description of their produced components and the automobile manufacturer had to integrate the components of the different suppliers. However, they usually had of adapt their own code to make it working with the third-party components. With AUTOSAR, a standardized definition of the interfaces is available and for this reasons also a standardized testability of the components can be managed. The code doesn t need to be adapted if a new component is simulated from a different supplier which saves times and money. Moreover, the configuration of the whole system like a change in the deployment of SWC to ECUs can be done very easily and the new configuration can be simulated instantly. With AUTOSAR, the application is independent of the hardware architecture. This new approach leads to an easier testability of components. In the past, the software was strongly coupled with the underlying hardware and therefore, the possibilities of a pure SiL simulation were limited. AUTOSAR considering this problem and introduced a VFB. As it was shown in section 3.3.1, a VFB simulation is possible which has the main advantage that it can be done in an early development stage and reduced the risk of finding errors in the software architecture very late which can lead to a big redesign and high expenditures. Finally, the AUTOSAR consortium consists of many different automobile manufacturers, automotive suppliers and tool developers and it is still growing. Therefore, it can be expected that more and more tool support for simulating AUTOSAR architectures will be available in the future.
16 16 REFERENCES References  Simulation Article, Roger D. Smith, 1998   Computer Simulation: The Art and Science of Digital World Construction, Paul A. Fishwick   Using simulation tools for embedded systems software development, Jakob Engblom, Virtutech, 2007  Software Engineering for Embedded Systems, Verification & Validation, Holger Giese, 2008/2009   Testing Embedded Software, Bart Broekman and Edwin Notenboom, 2003  V-Modell 1997: Entwicklungsstandard für IT-Systeme des Bundes,  Softwareentwicklung eingebetteter Systeme, Peter Scholz, Axel Springer Verlang, ISSN  Automatisierter Closed-Loop-Softwaretest eingebetteter Motorsteuerfunktionen, Sven Rebeschieß, Thomas Liebezeit, Uzmee Bazarsuren,  Testautomatisierung in der Hardware-in-the-Loop Simulation, Dr.-Ing. Clemens Gühmann, Dipl.-Ing. Jens Riese, IAV GmbH Berlin  AUTOSAR Modeling Guide, TargetLink 3.0, July 2008, dspace  Production Code Generation Guide, TargetLink 3.0, July 2008, dspace  Paper zum 3. Workshop Automotive Software Engineering, Informatik 2005   SystemDesk Guide For SystemDesk 2.0, Release 6.3, November 2008, dspace  Modeling of AUTOSAR using SystemDesk, Sebastian Wätzoldt  AUTOSAR Methodology & Templates, Regina Hebig  Software Architectue, Warschofsky  Specification of the Virtual Functional Bus,  Technical Overview,  Runtime Environment & Virtual Function Bus, Nico Naumann  Data Dictionary Basic Concepts Guide, TargetLink 3.0, July 2008, dspace
Testen von Embedded Systems Hardware in the Loop (HIL) Testing VU 2.0, 182.117, WS 2008/09 Raimund dkirner Testing Embedded Software Testing the whole system including the physical environment is not possible
AUTOSAR Software Architecture Robert Warschofsky Hasso-Plattner-Institute für Softwaresystemtechnik Abstract. AUTOSAR supports the re-use of software and hardware components of automotive electronic systems.
Seminar Automotive Open Systems Architecture Modeling and Development of AUTOSAR Systems using SystemDesk Sebastian Wätzoldt Hasso-Plattner-Institut for IT Systems Engineering at the University of Potsdam
2008-01-1469 Best Practices for Verification, Validation, and in Model- Based Design Copyright 2008 The MathWorks, Inc. Brett Murphy, Amory Wakefield, and Jon Friedman The MathWorks, Inc. ABSTRACT Model-Based
2008-01-0383 Development of AUTOSAR Software Components within Model-Based Design Copyright 2008 The MathWorks, Inc. Guido Sandmann Automotive Marketing Manager, EMEA The MathWorks Richard Thompson Senior
Model Based System Engineering (MBSE) For Accelerating Software Development Cycle Manish Patil Sujith Annamaneni September 2015 1 Contents 1. Abstract... 3 2. MBSE Overview... 4 3. MBSE Development Cycle...
PAGE 24 EB AUTOMOTIVE Industrialized integration and validation of TargetLink models for series production Continuous Software Production The complexity of software systems in vehicles is increasing at
User-friendly Configuration of AUTOSAR ECUs with Specialized Software Tools The simple CAN ECU is a thing of the past. Now, a typical ECU utilizes many functions of the AUTOSAR basic software to perform
www.dspace.com Model-Based Development of Safety-Critical Software: Safe and Effi cient Translation of Sicherheitskritische Software entwickeln Published at: MEDengineering, 06/2012 Software for safety-critical
Rapid Control Prototyping for Automotive Control Software Kiran K Kulkarni Application Expert ETAS Automotive, India 1 Rapid Control Prototyping for Automotive Control Software Agenda Basics on Prototyping
MATLAB Digest Converting Models from Floating Point to Fixed Point for Production Code Generation By Bill Chou and Tom Erkkinen An essential step in embedded software development, floating- to fixed-point
Chip simulation of automotive ECUs Jakob Mauss, QTronic GmbH Matthias Simons, Daimler AG 9. Symposium Steuerungssysteme für automobile Antriebe Berlin-Tempelhof, 20.-21.09.2012 Outline of the talk Chip
Hardware-Software Implementation With Model-Based Design Sudhir Sharma Product Manager, HDL Code Generation And Verification The MathWorks 2007 The MathWorks, Inc. Agenda What is the System Design Challenge
Software development Do AUTOSAR and functional safety rule each other out? While simplicity is a factor in safety-critical applications, AUTOSAR has over 6,000 configuration parameters and well over 100,000
Validating Diagnostics in Early Development Stages Explanations by means of an Example of an automatic exterior lighting control Dipl.-Ing. Valentin Adam, Daimler AG Dipl.-Ing. Matthias Kohlweyer, Daimler
Presented by: Jens Svensson, Volvo 3P Welcome to is one of the world's leading suppliers of transport solutions for commercial use. We also provide complete solutions for financing and service. Volvo Trucks
AutoSAR Overview FESA Workshop at KTH 2010 04 12 Prof. Jakob Axelsson Volvo Cars and Mälardalen University This presentation is based on a tutorial prepared by the AutoSAR Consortium AUTOSAR Members Status
Autosar Automotive Open System Architecture How are vehicle functions implemented today? Each function has it s own system although they may communicate through a bus Each function has it s own microcontroller
AUTOSAR Runtime Environment and Virtual Function Bus Nico Naumann firstname.lastname@example.org Department for System Analysis and Modeling Hasso-Plattner Institute for IT-Systems Engineering Prof.-Dr.-Helmert-Str.
Model-Based Design for Safety Critical Applications Bill Potter The MathWorks 2007 The MathWorks, Inc. Attributes of Safety Critical Systems Reliably perform intended function Contain no unintended function
Automotive Software Engineering List of Chapters: 1. Introduction and Overview 1.1 The Driver Vehicle Environment System 1.1.1 Design and Method of Operation of Vehicle Electronic 1.1.2 Electronic of the
Embedded Software for FlexRay Systems Special aspects and benefits of implementing modularized software Standardized software components will help in mastering the growing complexity of the interplay of
AUTOSAR ECU development process using DaVinci and MICROSAR from Vector English translation of a Japanese technical article from Mitsubishi Motors Corporation AUTOSAR is a group paving the way for the standardization
Multi-domain Model-driven Development Developing Electrical Propulsion System at Volvo Cars Jonn Lantz Technical Specialist, Electric Propulsion Systems @ Volvo Car Group Jonn.Lantz@volvocars.com 1 Partners
Overview of Existing Safeguarding Techniques for Automatically Generated Code Ingo Stürmer Member of the ACM email@example.com Daniela Weinberg Fraunhofer FIRST Computer Architecture and Software Technology
International Journal of Computer Applications (975 8887) Volume 99 No.12, August 214 Performance Study based on Matlab Modeling for Hybrid Electric Vehicles Mihai-Ovidiu Nicolaica PhD Student, Faculty
Copyright 2010 SAE International 2010-01-0431 Advanced Techniques for Simulating ECU C-code on the PC Vivek Jaikamal ETAS Inc. Thomas Zurawka SYSTECS Informationssysteme GmbH ABSTRACT Over the last two
Evaluation Environment for AUTOSAR Autocode in Motor Control Units Diploma Thesis Mike Gemünde July, 2008 Supervised by Prof. Dr. Klaus Schneider Peter Bolz Robert BOSCH GmbH DGS EC/ESB Embedded Systems
Software Development with Real- Time Workshop Embedded Coder Nigel Holliday Thales 2 Contents Who are we, where are we, what do we do Why do we want to use Model-Based Design Our Approach to Model-Based
Automatic Code Generation Embedded Control Systems Fall 2012 1 Software Development: Waterfall Model Requirements Design Implementation Verification Maintenance 2 Software Development: V diagram Project
Fixed-Point Design in MATLAB and Simulink Gaurav Dubey Senior Team Lead - Pilot Engineering Gaurav.Dubey@mathworks.in 2013 The MathWorks, Inc. 1 What are you looking for? How can I convert an algorithm
Deeply Embedded Real-Time Hypervisors for the Automotive Domain Dr. Gary Morgan, ETAS/ESC 1 Public ETAS/ESC 2014-02-20 ETAS GmbH 2014. All rights reserved, also regarding any disposal, exploitation, reproduction,
BMW Car IT GmbH. - First Experiences and the Migration Strategy of the BMW Group Dr. Christian, BMW Car IT Page 2 - First Experiences. Overview. 1. Focus of this talk: Model based development under the
Stuttgart, Testing Expo 2012 Virtual Integration and Consistent Testing of Advanced Driver Assistance Functions 2012-06-12 Jürgen Schüling Agenda Introduction and Motivation State of the Art Hardware in
COVER STORY Virtual Design You will find the figures mentioned in this article in the German issue of Automotive Electronics beginning on page 8. Virtuelles Design von Kfz-Elektronik-Netzwerken Von der
I can make just such ones if I had tools, and I could make tools if I had tools to make them with. -Eli Whitney Automotive Software Development and Model Based Design (Matlab & Simulink) Ian M. Alferez,
Setting up a Local Interconnect Network (LIN) using dspace MicroAutoBox 1401/1501 Simulink Blocks Guiseppe Ferro Design Team 4 3/22/13 Executive Summary Learn how to setup and properly use the Real- Time
OPC COMMUNICATION IN REAL TIME M. Mrosko, L. Mrafko Slovak University of Technology, Faculty of Electrical Engineering and Information Technology Ilkovičova 3, 812 19 Bratislava, Slovak Republic Abstract
CycurHSM An Automotive-qualified Software Stack for Hardware Security Modules Dr. Frederic Stumpf, ESCRYPT GmbH Embedded Security, Stuttgart, Germany 1 Introduction Electronic Control Units (ECU) are embedded
Product Information Table of Contents 1 Operating Systems for ECUs... 3 2 MICROSAR.OS The Real-Time Operating System for the AUTOSAR Standard... 3 2.1 Overview of Advantages... 3 2.2 Properties... 4 2.3
2015 The MathWorks, Inc. Simulink for System and Algorithm Modeling Introduction to System Modeling Outline 2-2 Model-Based Design Types of modeling System modeling with Simulink Modeling steps Model-Based
Model-Based Design for Embedded Systems Dr. Simon Ginsburg Application Engineering 2008 The MathWorks, Inc. Embedded Application Development Requirements Management Configuration Management Process and
Development Distr. Systems Model-based Electric/Electronic Development from Architecture Design to Series-Production Readiness ENGLISH 2 Model-based Electric/Electronic Development from Architecture Design
Continuous Integration Build-Test-Delivery (CI-BTD) Framework in compliance with ISO26262 Manish Patil Sathishkumar T September 2015 1 Contents Abstract... 3 1. Introduction... 3 2. Industry Challenges...
BEST Robotic, Inc. MATLAB/Simulink Team Training Programming With MATLAB/Simulink September 20, 2014 BISON BEST 1 What You ll Need Minimum System Requirements Microsoft Windows XP or Later 32-bit or 64-bit
DEVELOPMENT E l e c t r i c m o t o r s Electric motor emulator versus rotating test rig A controversial issue among experts is whether real-time model-based electric motor emulation can replace a conventional
Tackling the Complexity of Timing-relevant Deployment Decisions in Multicore-based Embedded Automotive Software Systems Rolf Schneider, AUDI AG 1 Topics Introduction Project ARAMiS ARAMiS Automotive LSSI
Safety and Security Features in AUTOSAR Nagarjuna Rao Kandimala, Michal Sojka Czech Technical University in Prague 166 27 Praha 6, Czech Republic Thursday 15 th November, 2012 Contents 1 Introduction 2
LIN A real Plug 'n' Play Bus System? Standardized application functions enable the possibility for flexible, fast and cost effective LIN developments. Therefore Plug n Play will also be possible for automotive
2008 International Conference on Software Testing, Verification, and Validation Model-based Testing of Automotive Systems Eckard Bringmann, Andreas Krämer PikeTec GmbH, Germany Eckard.Bringmann@PikeTec.com,
dspace User Conference Body Subsystems Test Automation using the dspace Hardware-in-the-Loop setup Venkata RK Pinnelli Suresh H Mohammed Haneefa Kolari 14-Sep-2012 General Motors Testing Environments Test
Plug and Play Solution for AUTOSAR Software Components The interfaces defined in the AUTOSAR standard enable an easier assembly of the ECU application out of components from different suppliers. However,
A Lightweight Framework for Testing Safety-critical Component-based Systems on Embedded Targets Nermin Kajtazovic, Andrea Höller, Tobias Rauter, and Christian Kreiner Institute for Technical Informatics,
Wiederverwendung von Testfällen bei der modellbasierten SW-Entwicklung DGLR Workshop "Verifikation in der modellbasierten Software-Entwicklung" Garching, 04 October 2011 Dipl.-Ing. Peter Hermle, Key Account
, pp.97-108 http://dx.doi.org/10.14257/ijseia.2014.8.6.08 Designing and Embodiment of Software that Creates Middle Ware for Resource Management in Embedded System Suk Hwan Moon and Cheol sick Lee Department
MotoHawk Software Model-Based Embedded Development Product Specification 37747 (Revision NEW, 01/2015) Rapid Control Development System on Real Production Hardware MotoHawk, an add-on to MATLAB/Simulink,
Networking Heavy-Duty Vehicles Based on SAE J1939 From Parameter Group to plug-and-play Application In networking ECUs in heavy-duty vehicles, it is the J1939 protocol that plays a key role. J1939 networks
Model-Based Extension of AUTOSAR for Architectural Online Reconfiguration Basil Becker 1, Holger Giese 1, Stefan Neumann 1, Martin Schenck 2 and Arian Treffer 2 Hasso-Plattner-Institute at the University
Model-based Testing of Automotive Systems Eckard Bringmann, Andreas Krämer PikeTec GmbH, Germany Eckard.Bringmann@PikeTec.com, Andreas.Kraemer@PikeTec.com Abstract In recent years the development of automotive
Page 6 santerno Power inverters: Efficient energy transformation through efficient TargetLink code Upva page 7 lue Energy Every day, the amount of energy delivered by the sun is 15,000 times the current
EE289 Lab Fall 2009 LAB 4. Ambient Noise Reduction 1 Introduction Noise canceling devices reduce unwanted ambient noise (acoustic noise) by means of active noise control. Among these devices are noise-canceling
Introduction to Simulink & Stateflow Coorous Mohtadi 1 Key Message Simulink and Stateflow provide: A powerful environment for modelling real processes... and are fully integrated with the MATLAB environment.
page 34 Delphi Diesel systems Plug & Play Various ECUs tested by automated sequences page 35 Delphi Diesel Systems has successfully developed automated integration and feature tests for various ECUs for
Introduction to Hans-Christian von der Wense Munich, Germany Overview Progress in Automotive Electronics and it s Impacts on Networking LIN Consortium LIN Concept Physical Layer Data Link Layer LIN Network
Ingo Stürmer, Dietrich Travkin Automated Transformation of MATLAB Simulink and Stateflow Models Ingo Stürmer Model Engineering Solutions Dietrich Travkin University of Paderborn Object-oriented Modeling
Standardized Runtime platforms and component integration AutoSAR and ARINC653 Ákos Horváth András Balogh Dept. of Measurement and Information Systems Budapest University of Technology and Economics Department
EBERSPÄCHER ELECTRONICS automotive bus systems solutions for network analysis DRIVING THE MOBILITY OF TOMORROW 2 AUTOmotive bus systems System Overview Analyzing Networks in all Development Phases Control
Volume 2, Issue 8, August 2012 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Development of
Methodology and Templates in AUTOSAR Regina Hebig Hasso Plattner Institut Abstract. AUTOSAR (AUTomotive Open System Architecture) is a worldwide development partnership of car manufacturers and suppliers.
Sensors Actuators ECU Hardware Development OEM Supplier System Architecture Function Network Function Mapping ECUs Communication Gateways Busses Wiring Harness Development Integration Conformance Network
- Hans J. Holberg SVP Marketing & Sales, BTC Embedded Systems AG Buschstr. 1, 26127 Oldenburg, Germany firstname.lastname@example.org Dr. Udo Brockmeyer CEO, BTC Embedded Systems AG Buschstr. 1, 26127 Oldenburg, Germany
The V850 Integrated Development Environment in Conjunction with MAT...iles and More / Web Magazine -Innovation Channel- / NEC Electronics Volume 53 (Feb 22, 2006) The V850 Integrated Development Environment
Virtual Powertrain Calibration at GM Becomes a Reality 2010-01-2323 Published 10/19/2010 Keith Lang and Michael Kropinski General Motors LLC Tim Foster ETAS Inc. Copyright 2010 SAE International ABSTRACT
01PC-422 Software Development for Multiple OEMs Using Tool Configured Middleware for CAN Communication Pascal Jost IAS, University of Stuttgart, Germany Stephan Hoffmann Vector CANtech Inc., USA Copyright
Hardware-independent Software Development with Stefan Bunzel, Khosrau Heidary(Continental); Simon Fürst, Andre Lajtkep (BMW Group); JürgenMössinger, Jürgen Cordes(Bosch); StefanSchmerler, ChristianKühn,
Spot server problems before they are noticed The system s really slow today! How often have you heard that? Finding the solution isn t so easy. The obvious questions to ask are why is it running slowly
OMG @ Hyatt Regency Cambridge Systems Assurance and Behavior Modeling : Requirements for OMG September 22 nd, 2010 Akira Ohata TOYOTA MOTOR CORPORATION Ohata s Introduction Higashifuji Technical Center
Product Development Flow Including Model- Based Design and System-Level Functional Verification 2006 The MathWorks, Inc. Ascension Vizinho-Coutry, email@example.com Agenda Introduction to Model-Based-Design
Open Source Software Title Experiences and considerations about open source software for standard software components in automotive environments 2 Overview Experiences Project Findings Considerations X-by-wire
DS1104 R&D Controller Board Cost-effective system for controller development Highlights Single-board system with real-time hardware and comprehensive I/O Cost-effective PCI hardware for use in PCs Application
Part I. Introduction In the development of modern vehicles, the infotainment system  belongs to the innovative area. In comparison to the conventional areas such as the motor, body construction and
Application of Software Watchdog as a Dependability Software Service for Automotive Safety Relevant Systems Xi Chen Juejing Feng Martin Hiller Vera Lauer RWTH Aachen University Volvo Technology Aachen,