Timing Veriﬁcation of Application Soft- ware in Multi-Core

Timing Verification of Application Soft-ware in Multi-Core Systems

A Methodology to Verify Timing Precisely in Multi-Core Sys-tems

Master’s thesis in Computer Systems and Networks

Aravindan Anbarasu

Department of Computer Science and EngineeringCHALMERS UNIVERSITY OF TECHNOLOGYUNIVERSITY OF GOTHENBURGGothenburg, Sweden 2019

Master’s thesis 2019

Timing Verification of Application Software inMulti-Core Systems

A Methodology to Verify Timing Precisely in Multi-Core Systems

Aravindan Anbarasu

Department of Computer Science and EngineeringChalmers University of Technology

University of GothenburgGothenburg, Sweden 2019

Timing Verification of Application Software in Multi-Core SystemsA Methodology to Verify Timing Precisely in Multi-Core SystemsAravindan Anbarasu

© Aravindan Anbarasu, 2019.

Supervisor: Jan-Philipp Steghöfer, Computer Science and Engineering DepartmentAdvisor: Henrik Lönn, Volvo Group Trucks TechnologyExaminer: Erland Jonsson, Computer Science and Engineering Department

Master’s Thesis 2019Department of Computer Science and EngineeringChalmers University of Technology and University of GothenburgSE-412 96 GothenburgTelephone +46 31 772 1000

Typeset in LATEXGothenburg, Sweden 2019

iv

Timing Verification of Application Software in Multi-Core SystemsA Methodology to Verify Timing Precisely in Multi-Core SystemsAravindan AnbarasuDepartment of Computer Science and EngineeringChalmers University of Technology and University of Gothenburg

AbstractVehicles of today are becoming more autonomous with advanced technologies to ob-tain real-time information regarding the road and traffic situations. Computationalprocessing must keep pace with this growth in order to meet the timing require-ments. Timing constraints are crucial for a safety-critical automotive embeddedsystem, as the consequence of ignoring timing could scale from loss of comfort tolife threatening situations. Unfortunately, an Electronic Control Unit (ECU) witha single-core will not have enough computational capacity to perform heavy dataprocessing in real-time to meet the timing constraints. So the automotive indus-try are replacing their traditional single-core ECUs with multicore ECUs which canperform parallel data processing to meet the timing constraints whenever necessary.The increasing functionality of automotive systems requires not only the use of com-plex hardware, but it is also very important to identify and prototype methods tocapture and verify timing requirements for software components on such multi-coresystems, as it impacts their safety as well as their perceived customer value.

The aim of this project is to verify timing constraints for software componentson a multi-core platform. The thesis shows how architectural models (EAST-ADL/AUTOSAR) and models capable of precise timing analysis (AMALTHEA)shall be integrated/related for meticulous timing verification. This thesis automatesthe transformation of an EAST-ADL/AUTOSAR model to an AMALTHEA model,with the intention to retain the EAST-ADL/AUTOSAR models which are the stan-dardized software architecture for automotive ECUs and use the AMALTHEAmodelonly for precise timing verification. A comparison of the different tools that are ca-pable of simulating AMALTHEA models is also presented. The results of this thesiswork are a methodology and prototype tooling for precise timing verification inmulti-core systems.

Keywords: Vehicles, Timing constraints, ECU, Multi-core, EAST-ADL, AUTOSAR,AMALTHEA

v

AcknowledgementsFirst and foremost, I would like to thank my industrial advisor Henrik Lönn and myacademic supervisor Jan-Philipp Steghöfer for their support, advice, and criticismduring this entire thesis work. Needless to say, without their constant support andvaluable ideas, this thesis work would not have been possible. Furthermore, I wouldlike to thank my examiner Erland Jonsson for his support and time throughout thiswork. And last but not least, I am thankful to all my unnamed friends at Volvo fortheir help and support.

Aravindan Anbarasu, Gothenburg, June 2019

vii

Contents

List of Figures xi

List of Tables xiii

Listings xv

Acronyms xvii

1 Introduction 1

2 Technical Background 52.1 EAST-ADL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 AUTOSAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 AMALTHEA/APP4MC . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Tool Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 eXtensible Stylesheet Language Transformations . . . . . . . . . . . . 15

3 Literature Review 173.1 Relevant Literature from the Problem Domain . . . . . . . . . . . . . 173.2 Relevant Literature on Potential Solution Approaches . . . . . . . . . 183.3 Previous Work within the Project . . . . . . . . . . . . . . . . . . . . 18

4 Evaluation Criteria 19

5 Methods 21

6 Results 256.1 Results of each Iteration . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1.1 Iteration 1: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.2 Iteration 2: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.1.3 Iteration 3: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7 Discussion 457.1 Comparison of the effort to extend the EAST-ADL and AUTOSAR

models to AMALTHEA . . . . . . . . . . . . . . . . . . . . . . . . . 467.2 Engineering Work Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 477.3 Limitations in Simulation/Analysis Tool Platform . . . . . . . . . . . 487.4 Possible Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

ix

Contents

8 Conclusion 51

Bibliography 53

A Appendix 1 IA.1 Code Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

x

List of Figures

1.1 Engineering Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 EAST-ADL System Model [6] . . . . . . . . . . . . . . . . . . . . . . 52.2 Overview of AUTOSAR Software Layers [17] . . . . . . . . . . . . . . 72.3 Overview of Component Types [15] . . . . . . . . . . . . . . . . . . . 82.4 Port Interfaces in the AUTOSAR meta-model [15] . . . . . . . . . . . 102.5 Overview of the contents of AMALTHEA meta-model [4] . . . . . . . 112.6 Process Flow in XSLT [13] . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Action Research Loop . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.1 Functional Design Architecture of BBW component in AREAToP . . 266.2 Event Function Flow Port of Anti-lock Braking System (ABS) in

AREAToP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.3 Execution Time Constraint for ABS in AREAToP . . . . . . . . . . . 286.4 Event Function for ABS in AREAToP . . . . . . . . . . . . . . . . . 296.5 Periodic Constraint for ABS in AREAToP . . . . . . . . . . . . . . . 296.6 Precedence Constraint for ABS and Brake Actuator in AREAToP . . 296.7 Event Chain for Brake-by-wire (BBW) in AREAToP . . . . . . . . . 306.8 Age Constraint for BBW in AREAToP . . . . . . . . . . . . . . . . . 306.9 Hardware Component Prototypes of BBW in AREAToP . . . . . . . 316.10 Model Transformation of EAST-ADL model in AREAToP . . . . . . 326.11 Editing AMALTHEA model in APP4MC . . . . . . . . . . . . . . . . 326.12 Task Graph for imported BBW in Silexica . . . . . . . . . . . . . . . 336.13 Scheduler Configuration Editor in SLX . . . . . . . . . . . . . . . . . 336.14 Schedule for Tasks in SLX . . . . . . . . . . . . . . . . . . . . . . . . 346.15 Validating AMALTHEA model in TA tool suite . . . . . . . . . . . . 376.16 Simulation of BBW model in TA tool suite . . . . . . . . . . . . . . . 376.17 Requirements table showing Response Time requirements for BBW

model in TA tool suite . . . . . . . . . . . . . . . . . . . . . . . . . . 386.18 Event Chain Requirement table for BBW model in TA tool suite . . . 386.19 Process table showing task metrics for BBW model in TA tool suite . 396.20 Runnable table showing runnable metrics for BBW model in TA tool

suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.21 Hardware Resource table showing CPU metrics for BBW model in

TA tool suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.22 AUTOSAR model of BBW in AREAToP . . . . . . . . . . . . . . . . 41

xi

List of Figures

6.23 Model Transformation of AUTOSAR model in AREAToP . . . . . . 43

7.1 Optimized Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.2 Engineering Work Flow Loop . . . . . . . . . . . . . . . . . . . . . . 477.3 Platform Models Supported by Silexica Tool [10] . . . . . . . . . . . . 487.4 Supported Processor Models for TA Tool Suite [11] . . . . . . . . . . 49

xii

List of Tables

6.1 Mapping between EAST-ADL and AMALTHEA elements during ModelTransformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.2 Mapping between AUTOSAR and AMALTHEA elements during ModelTransformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.1 Comparison of model elements covered by AUTOSAR, AMALTHEAand EAST-ADL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

xiii

List of Tables

xiv

Listings

A.1 XSLT code for transforming EAST-ADL to AMALTHEA model . . . IA.2 XSLT code for transforming AUTOSAR to AMALTHEA model . . . VIIIA.3 AUTOSAR model for BBW component . . . . . . . . . . . . . . . . . XIV

xv

Listings

xvi

Acronyms

ECU Electronic Control Unit

AUTOSAR AUTomotive Open System ARchitecture

FAA Functional Analysis Architecture

FDA Functional Design Architecture

HDA Hardware Design Architecture

ADL Architecture Description Language

RTE Runtime Environment

BSW Basic Software

ISR Interrupt Service Routine

AREAToP AUTOSAR EAST-ADL Tool Platform

EPL Eclipse Public License

Artop AUTOSAR Tool Platform

EATOP EAST-ADL Tool Platform

TA Timing Architects

SLX Silexica

XML eXtensible Markup Language

XSLT eXtensible Stylesheet Language Transformations

RCM Rubus Component Model

xvii

0. Acronyms

BBW Brake-by-wire

ABS Anti-lock Braking System

xviii

1Introduction

BackgroundNowadays, autonomous vehicles are evolving with advanced technologies to supportautonomous driving and safety features, which in turn requires enormous comput-ing capabilities. Unfortunately, the computing capacity of a single-core will notbe enough to meet these requirements. So the automotive industry has made amove from single-core to multi-core systems that can perform heavy data process-ing in real-time. This is one of the biggest challenges in the automotive industry,because the existing applications can not realize instant benefit because they werenot designed initially to run on such multi-core architectures [5]. Also, most of thesystems and applications have been migrated into AUTOSAR compatible architec-tures. Both trends imply the need for a new development environment that canserve these requirements. Model-based approaches have been widely used in theautomotive industry for managing such modelling complexities. Handling timingrequirements is one of the most important things to be taken care in a modellingapproach. This is because timing requirements like execution and response times arecrucial for a safety-critical single and multi-core automotive systems, and neglectingtiming could range from loss of comfort to life-threatening situations. Timing re-lated issues have always been a big concern while modelling automotive embeddedsystems. In particular, it is very hard to verify the time in multi-core systems withthe prevailing standard modelling languages which have only limited support formulti-core systems.

Therefore, it is very important to identify and prototype methods to capture andverify timing requirements for software components on multi-core systems. Based onthe current state of the art research and industry requirements, modelling languageslike EAST-ADL and AUTOSAR provide support for modelling multi-core systems.However, the level of details provided by them in terms of multi-core resource uti-lization will not be sufficient for a precise timing verification in multi-core systems.So a modeling language capable of precise timing analysis like AMALTHEA can bedeployed.

AimFor single core automotive systems, some domain specific modeling languages likeEAST-ADL/AUTOSAR exist already. But these model-based methodologies only

1

1. Introduction

have limited support for multi-core systems. So precise timing analysis cannot becaptured. To tackle this problem, a modeling language like AMALTHEA can beutilized, which provides extended support for multi-core platform. For example,AMALTHEA has additional support for software design constraints like RunnableAffinity Constraints that are used to define the mapping of runnable objects to spe-cific processing cores or scheduling units [4][5].

Rather than creating a new AMALTHEA system model from scratch for each soft-ware component, the idea is to transform the existing EAST-ADL/AUTOSARmodel into an AMALTHEA model via automation scripts to verify timing require-ments on the multi-core platform. The decision to transform is taken because theintention is to retain AUTOSAR (standard implementation level model) and EAST-ADL (complements AUTOSAR with descriptions at a higher level of abstractions)and use the AMALTHEA model mainly for precise timing analysis. Also, the thesisaims to find a tool that is best suited for simulating the AMALTHEA model.

Problem Statement

The thesis focuses on the following questions listed below:• How can one verify timing more precisely on a multi-core platform?• How can different timing modelling approaches be mapped to achieve meticu-

lous timing verification for multi-core systems?• How can one reduce the manual effort done during the model transformation

process?• Which is the best tool to simulate the model that is capable of precise timing

verification for multi-core systems?

Intended Project Result

Figure 1.1: Engineering Loop

The results/outcome of this thesis work will be a process/methodology and proto-type tooling which will be beneficial for the embedded engineers during the engi-neering workflow as shown in Figure 1.1.

2

1. Introduction

LimitationsThe idea of this thesis is not to invent new ways to do timing analysis but to showhow architecture models and multicore deployment models shall be integrated/re-lated. This will be helpful for the automotive industry in finding ways to relate thearchitectural models with models capable of analysis.

3

1. Introduction

4

2Technical Background

This chapter provides some technical background required to give the reader suf-ficient information about the concepts discussed in this project. A background onEAST-ADL, AUTOSAR and AMALTHEA models are presented with in depth in-formation regarding the relationship between them. The chapter also covers theinformation regarding the tools and transformation language used in the thesis.

2.1 EAST-ADL

Figure 2.1: EAST-ADL System Model [6]

EAST-ADL is an Architecture Description Language (ADL) for automotive embed-ded systems initially defined to complement AUTOSAR with descriptions at a higherlevel of abstraction [6]. The EAST-ADL model is structured in several abstraction

5

2. Technical Background

levels, that contain vehicle features, requirements, software components, hardwarecomponents, functions, variability and communication details [7]. The top-level con-tainer of the EAST-ADL model is the System Model as shown in Figure 2.1, whichrepresents the vehicle’s electrical/electronic system details and its related concepts[6]. The EAST-ADL meta-model is organized into the following four abstractionlevels, namely Vehicle level, Analysis level, Design level and Implementation level.

Vehicle levelThe Vehicle level provides support for configuration and definition of product linesat the highest abstraction level in terms of features [6]. A feature could be anycharacteristic property that may or may not be present in the individual variantof the vehicle. The vehicle level contains an arbitrary set of feature models torepresent the intended functionality. The feature model contains the vehicle featuresthat reflect the vehicle configurations [6]. In general, there will be a core technicalfeature model and one or more product feature models. The core technical featuremodel defines the overall features of the complete system on vehicle level, and theproduct feature models provide an orthogonal view on the core technical featuremodel [6].

Analysis levelThe Analysis level contains the abstract functional definition of the electrical/elec-tronic system in the vehicle with some important internal and external interfaces.The Analysis level includes the Functional Analysis Architecture (FAA), that rep-resents the functional structure and realizes the vehicle features to capture analysissupport of what the system shall do [6]. On Analysis level, Functional AnalysisArchitecture is the root component of the function compositional hierarchy. InFAA, Functional component modeling is the main modeling concept used, wheretwo functions interact with each other via ports that are connected by connectors[6].

Design levelThe Design level represents the abstract design definition of the electrical/electronicsystem in the vehicle [6]. It also contains the non-transparent infrastructure func-tionality details like error handling and mode change to estimate the application’sbehaviour [6]. It includes the Functional Design Architecture (FDA), the HardwareDesign Architecture (HDA).

Functional Design Architecture (FDA)

The Functional Design Architecture represents a decomposition of functionalitiesmentioned in the Analysis level, including behavioral description but excluding soft-ware implementation constraints [6]. FDA is supposed to implement all the func-tionalities at the vehicle level, if no FAA has been defined during the modellingprocess [6]. With FDA, it possible to meet constraints regarding non-functional

6


properties such as allocation, efficiency, or reuse. Entities in the FDA and entitiesin the FAA are related by an n-to-m mapping (Realization Relationships) [6]. Themain modeling concept applied in FDA is functional modeling, where each functioncommunicates with another function via ports that are connected by connectorsowned by the composing function [6].

Hardware Design Architecture (HDA)

The HDA represents the hardware architecture of the embedded system. The HDAmodels ECUs, sensors, actuators and communication links [6]. The HDA also actsas an allocation target for the functions of the FDA [6].

Implementation levelThe Implementation level represents the software and hardware architecture of thesystem in the vehicle. It refers to the system element in an AUTOSAR model anddoes not have any EAST-ADL specific standards [6].

2.2 AUTOSAR

Figure 2.2: Overview of AUTOSAR Software Layers [17]

AUTomotive Open System ARchitecture (AUTOSAR) is an open and standard-ized software, jointly developed by the vehicle manufacturers, suppliers and ser-vice providers [16]. AUTOSAR aims to enhance complexity management of in-tegrated Electrical/Electronic architectures through increased reuse and exchange-ability of software modules between original equipment manufacturers and suppliers.AUTOSAR standardizes two software platforms, namely Classic and Adaptive. Thisthesis focuses only on classic AUTOSAR.

7


Software Architecture

AUTOSAR uses a three-layered architecture, namely Application layer, RuntimeEnvironment (RTE) layer and Basic Software (BSW) layer which run on a micro-controller as shown in Figure 2.2. The Application layer includes various appli-cation software components (AUTOSAR software components and/or AUTOSARsensor/actuator components) that are designed to execute a specific set of tasks, asper the use-case [20]. The RTE is at the heart of the AUTOSAR ECU architectureand provides communication services to the application software components. Themain purpose of having the RTE layer is to make AUTOSAR software componentscompletely ECU independent by abstracting the information exchange between theapplication software components and the Basic Software [17]. The BSW layer in-cludes the standardized software modules that offer services necessary to run thefunctional part of the upper software layers.

Component Types

Figure 2.3: Overview of Component Types [15]

A general outline of the component types in AUTOSAR is shown in Figure 2.3.Some of the component types that are more relevant to this thesis are describedbelow,

8


SwComponentType

SwComponentType is the base class for all AUTOSAR software components [15].The abstract SwComponentType cannot be instantiated, but can be referenced byone or many SwComponentPrototypes.

SwComponentPrototype

SwComponentPrototype implements the usage of a SwComponentType in a spe-cific role, i.e., they are used to instantiate the SwComponentType [15]. In general,arbitrary numbers of SwComponentPrototypes can be instantiated from the sameSwComponentType. All the SwComponentPrototypes instantiated from the sameSwComponentType will have the same properties of that corresponding SwCom-ponentType. For example, if SwComponentType is defined with 3 Provider Port-Prototypes and 4 Receiver PortPrototypes then all the SwComponentPrototypespointing to that SwComponentType will have the same number of Receiver andProvider PortPrototypes.

CompositionSwComponentType

Encapsulation of specific functionality by aggregating existing software componentsis the main purpose of a CompositionSwComponentType [15]. CompositionSwCom-ponentType aggregates SwComponentPrototypes which in turn are typed by aSwComponentType. It also aggregates SwConnectors for primarily connecting SwCom-ponentPrototypes [15]. Because CompositionSwComponentType is also a SwCom-ponentType, it may be aggregated again into further CompositionSwComponent-Types [15]. CompositionSwComponentTypes do not add any new functionality tothe software components they aggregate. Representing the application software ofan entire vehicle in a single CompositionSwComponentType is one implication ofthe concept of CompositionSwComponentType [15].

AtomicSwComponentType

AtomicSwComponentType is derived from SwComponentType and it encapsulatesthe implementation of the functionality and behavior of the software components[15]. An atomic software component is atomic in the sense that it cannot be furtherdisintegrated into software components. Only AtomicSwComponentType can haveRunnableEntitys, which are the smallest code-fragment that are executed undercontrol of the RTE [15].

ApplicationSwComponentType

The ApplicationSwComponentType is a specialization of AtomicSwComponentTypethat uses all AUTOSAR communication mechanisms and services for representinghardware-independent application software [15]. The SwcInternalBehavior of an Ap-plicationSwComponentType contains the RTE information regarding the softwarecomponent, i.e., the RunnableEntities and the RTE Events they respond to [15].

9


Port Interfaces

Figure 2.4: Port Interfaces in the AUTOSAR meta-model [15]

A Port Interface is attached to every port on a software component, that describesthe data or operations that are provided or required by the port of that SoftwareComponent [21]. A Port Interface can be either a Parameter Interface, TriggerInterface, Mode Switch Interface or Non Volatile Data Interface [21] as shown inFigure 2.4. This thesis focuses only on Client-Server Interface and Sender-ReceiverInterface.

Sender-Receiver Interface

The sender-receiver interface is a special kind of port-interface that are used forsender-receiver communication. The sender-receiver interface defines the data-elementsthat are sent by a sending component or received by a receiving component [21].Sender-Receiver interfaces are composed of variable data prototypes that used for

10


data exchange between software components and also specifies which data is trans-ferred from the sender to the receiver [21].

Client-Server Interface

The client-server interface is a special kind of port-interface that are used for client-server communication. The client-server interface defines the operations that areimplemented by the server component and that can be used by the client compo-nent [21]. In the client-server interface, a client is allowed to call an operation at aserver, which in turn provides the result to the client [21].

Interested readers can refer to [15] for more detailed information about the AUTOSARmodel.

2.3 AMALTHEA/APP4MC

Figure 2.5: Overview of the contents of AMALTHEA meta-model [4]

AMALTHEA is an open source project started in 2011 for engineering embeddedmulti and many-core software systems, because of the lack of multi-core support inthe development tools at that time [4]. In later years, AMALTHEA platform becamean official Eclipse project called APP4MC, which is an open source Eclipse tool plat-form that provides an AUTOSAR compliant system model called AMALTHEA foroptimizing embedded multi-core systems [2]. The AMALTHEA system model cov-ers engineering activities such as system/software modelling, partitioning, mapping,and tracing. The AMALTHEA model is sub-divided into eleven models, namelyComponents Model, Configuration Model, Constraints Model, Event Model, Hard-ware Model, Mapping Model, Measurement Model, OS Model, PropertyConstraintsModel, Stimuli Model and Software Model. Each of these models covers a particular

11


aspect of the system under development as in Figure 2.5.

The current version, Eclipse APP4MC v0.9.3 does not have support for simulationtools, visualization tools and graphical editors [5]. APP4MC typically addressesautomotive domain but it is also applicable to telecommunication and generic real-time systems. Interested readers can also refer to [5] for more information aboutthe AMALTHEA model. Some of the sub-models that are relevant to this thesis areexplained below,

Hardware ModelThe AMALTHEA hardware model is used to describe the hardware architectureof the embedded system. It includes details related to ECU, micro controllers,processing cores, memories, connections, additional peripherals, etc [5].

Mapping ModelThe mapping model provides information about the mappings and allocations fordifferent entities. The mapping details include, description of memory address loca-tion where the physical memory section is allocated, mapping of various elements toa specific memory, etc [5]. The allocation details include, Scheduler Allocation (asso-ciate a scheduler with a processing unit), Runnable Allocation (associate a runnablewith a scheduler), Task Allocation (associate a task with a scheduler) and InterruptService Routine (ISR) Allocation (associate an ISR with an interrupt controller) [5].

Operating System ModelThe Operating System model describes the functionality of an operating system. Itincludes details related to task scheduler (used to manage and distribute tasks usinga scheduling algorithm), interrupt controller (used to indicate an event that needsimmediate attention), semaphores (used to control access to a common resource bymultiple processes in a concurrent system such as a multitasking operating system),etc., thus providing a way to specify how access is given to certain system resources[5].

Stimuli ModelThe Stimuli model provides information about the stimulus and clock objects. Astimulus is responsible to activate processes in a different manner. For example,Event Stimulus (activation triggered by an event), Periodic Stimulus (periodic ac-tivation based on an offset, a recurrence and a jitter), Inter Process Stimulus (ac-tivation based on an explicit inter-process trigger), etc. The clock objects are usedto describe the progress of time for one or more variables in relation to global time[5]. The time of task activation can be different, if two equal stimuli have a differenttime base [5].

12


Software ModelThe Software model provides information about the entire functional behaviourof the software. This includes details regarding labels (data element located inmemory), runnables (run-time entity with instruction count) , tasks (collection ofrunnables), call graph (define how a task or ISR behaves during execution), processprototypes (define runnable order precedence), process chains (list of tasks repre-senting an end-to-end data processing path), etc [5].

Constraints ModelThe Constraints model provides information about the different kind of constraintsthat has to be satisfied during execution. This includes Runnable Affinity Con-straints (mapping of runnable objects to processing cores or scheduling units re-striction), Event Chain Latency Constraint (how long after a stimulus a corre-sponding response must occur), Data Affinity Constraints (mapping of label objectsto memory units restriction), Process Requirements for tasks(response-time restric-tion for tasks), Runnable Sequencing Constraints (restriction on execution orders ofrunnables), etc [5].

Event ModelThe Event model provides information about different event entities that can beused for the modeling of event chains and for some timing constraints. This includesProcess Event, Process Chain Event, Stimulus Event, Runnable Event, SemaphoreEvent, etc [5]. Each of these event entities has an event type that represents differentstate-transitions. Some of the event types are, activate (denotes that the entity isactivated by a stimulus), start (denotes that the entity starts to execute for thefirst time), preempt (denotes that the entity is stopped by the scheduler), resume(denotes that the entity continues execution on the same or other core) and terminate(denotes that the entity has finished execution) [5].

2.4 Tool Platform

Design ToolsThe thesis intends to use the AUTOSAR EAST-ADL Tool Platform (AREAToP)Technology Demonstrator tool developed by AB Volvo for designing EAST-ADLand AUTOSAR models.

AREAToP Technology Demonstrator

AREAToP Technology Demonstrator is a design tool developed by AB Volvo withan intention to design and develop both EAST-ADL and AUTOSAR models undera single tool platform. It is based on the model driven approach as basic engineeringmethodology. AREAToP is an implementation of the common base functionality of

13


AUTOSAR Tool Platform (Artop) and EAST-ADL Tool Platform (EATOP). How-ever, the tool has several of its own implementation of functionalities in the form ofsoftware plugins. One of the plugins used in this thesis is the Graph Modelling plu-gin, which enables the user to view a graphical representation of a selected elementalong with its ports and communication link as shown in 6.1. Interested readers canrefer [18] and [19] to learn more about the functionalities of EATOP and Artop toolplatforms respectively.

Simulation ToolsSince the AMALTHEA research project was started in 2011, only a few commercialtools provide support for simulating AMALTHEA models. This thesis focuses ontwo such tools, namely Silexica and Timing Architects (TA) tool suite.

SILEXICA

Silexica (SLX) is a multicore development tool that provides software executionawareness in the hardware and software inter-dependencies. The tool provides aprecise and full analysis of software inter-dependencies thereby helping to fully un-derstand the application behavior on a multi-core system [10]. With SLX, the inter-action between runnables and tasks, data dependencies and the program flow canbe revealed [10]. Additionally, information for parallelization such as core migrationpolicies and scheduler configuration are also revealed. Based on these information,runnable to task mapping as well as task to core mapping can be optimized [10].The tool is proprietary and a license cost has to be paid inorder to use it. A limitedperiod demo version is also available upon request.

SLX + AMALTHEA

The current version, SLX-2018.10 sp-1 of the tool platform comes with AMALTHEAsupport. With SLX the user can import an ALMATHEA model into a new projectand generate schedules. Once an AMALTHEA model is imported, the first step isthe Analyze phase, where the model is analyzed to get a clear understanding of theinter-task and inter-runnable dependencies [10]. Next step is the optimize phase,where SLX allows the user to parallelize selected tasks by creating a mapping oftasks to processing cores for the schedule creation. Finally, the tool allows the userto run the scheduler which computes schedules and the results of the simulationare displayed through gantt charts [10]. The tool also allows the user to export themodified AMALTHEA model after configuring the scheduler configuration.

TIMING ARCHITECTS TOOL SUITE

TA tool suite provides user-friendly tools for the design, simulation, verification andoptimization of embedded multi-core systems [11]. The TA tool suite is capableof providing an in-depth analysis of the timing behaviour and supports mappingof application software on different cores in a multi-core platform, which helps inincreasing the efficiency of multi-core real-time systems [11]. For each step in the

14


software project life-cycle, TA tool Suite provides a dedicated software product.This includes TA-Design, TA-Simulation, TA-Optimization and TA-Inspection [11].

TA-Design provides support for defining timing requirements of the application soft-ware through an interactive dynamic visualization [11]. TA-Simulation providessupport for model-based simulation of ECU timing behavior. It also aids in ana-lyzing the system behavior through graphical and table based evaluations of timingmetrics [11]. TA-Optimization provides support for the distribution and mapping ofapplication software on different cores in a multi-core platform [11]. TA-Inspectionprovides support for verification of the timing behavior of application software interms of deadlines, response times, utilization, and other metrics [11]. The tool isproprietary to the company (Vector) and a license cost has to be paid in-order touse it. A limited period demo version is also available upon request.

TA SUITE + AMALTHEA

The current version, 19.1 of the TA tool suite comes with AMALTHEA support.The TA tool suite allows the user to import an existing AMALTHEA model as a newproject. However, using TA-Design a new AMALTHEA model can also be createdfrom scratch. After the AMALTHEA model is imported/created, the TA tool suiteanalyzes the model and indicates the user for any inconsistencies in the model. Forexample, the periodic tasks might be missing the recurrence time value in the model.These inconsistencies can be fixed by editing the AMALTHEA model with the helpof TA-Design. Once the model has become error free, the TA tool suite allows theuser to perform the simulation with the help of TA-Simulation. The simulationresults (scheduling of tasks) are visualized via different views like gantt chart view,histogram view, etc [11]. The simulation results are analyzed via different metrictables like the process table, requirements table, hardware resource table, eventchain requirement table, etc. In case, if some of the timing requirements are notfulfilled, the user can use TA-Design to edit the AMALTHEA model accordinglyand perform a new simulation.

2.5 eXtensible Stylesheet Language Transforma-tions

eXtensible Stylesheet Language Transformations (XSLT) is the best known XMLtransformation language [12]. XSLT version 1.0 has been widely used for trans-forming XML documents into other XML documents since 1999 [12]. The XSLTprocessor takes an XML source document and an XSLT style sheet as inputs, andprocesses them to produce an output document as shown in Figure 2.6. In thisprocess, the source document is unaltered and the resultant output document willbe a new document based on the content of the source document. Xalan is a knownopen source XSLT 1.0 processor from the Apache Software Foundation available forJava and C++ [13].

15


Figure 2.6: Process Flow in XSLT [13]

The XSLT processor implements a fixed algorithm. Initially, the processor reads theXSLT style sheet and builds a source tree from the input XML document. Thenthe processor starts processing the source tree from the root node. The processortries to find the best-matching template for each node in the XSLT style sheetand evaluates the template’s contents. In general, the contents in each templateinstructs the processor to either process more nodes in the source tree or to createnew nodes in the result tree [13]. XML Path Language, shortly called XPath is amajor element in the XSLT standard that contains over 200 built-in functions tonavigate through the subsets of the source document tree and perform calculations.XSLT 1.0 uses XPath 1.0 to navigate through elements and attributes in an XMLdocument. Interested readers can also refer to [14] for more information about theXSLT syntax.

16

3Literature Review

3.1 Relevant Literature from the Problem Do-main

Bucaioni et al. [1] propose a methodology for early verification of non-functionalproperties like timing requirements during the design level within EAST-ADL, whichcould possibly reduce the expensive modifications later in the implementation level(Rubus Component Model) [1]. In general, the translation from the design to im-plementation level is performed manually, pushing the timing verification to imple-mentation phase [1]. The paper demonstrates a proof of concept to automate theintegration (through model transformations) between EAST-ADL and Rubus Com-ponent Model (RCM) on single/multi core platforms thereby enabling the earlyverification during the design phase itself [1]. For multi-core systems the authorspropose to use RCM as the implementation level for EAST-ADL because at theapplication software level, AUTOSAR does not differentiate between the controland the data flows, which is fundamental for providing early timing verification [1].Hence this paper [1] intends to substitute AUTOSAR with RCM at the implemen-tation level within EAST-ADL as it does not have extended support for multi-coresystems.

Mubeen et al. [22] propose an approach to represent the end-to-end timing mod-els. At a higher abstraction level, the approach provides timing information on thesystem models that are created with the EAST-ADL language utilizing the TIMingMOdel (TIMMO) methodology, annotated with timing information using TimingAugmented Description Language (TADL2) [22]. At the lower level, the approachuses RCM to represent the timing information. The paper proposes to choose RCMinstead of AUTOSAR for two reasons. Though the current AUTOSAR specificationprovides a timing model, it fails to specify a few low-level details which are neededto perform the end-to-end timing analysis like the control flow between functional-ities, etc [22]. The other reason is that the implementations built with RCM haverelatively smaller runtime footprints, i.e., memory overheads and timing [22].

From the literature [1] and [22], one can clearly see the deficits of the AUTOSARover RCM model. Since RCM is a proprietary modeling language developed byArcticus Systems, this thesis aims to experiment with some open source modelinglanguage like AMALTHEA.

17

3. Literature Review

3.2 Relevant Literature on Potential Solution Ap-proaches

APP4MC is an open source application platform project designed to utilize multi/-many core systems managing timing through simulation and continuous design [2].APP4MC uses AUTOSAR compliant data model called AMALTHEA for perform-ing timing and behavioural analysis and also provides basic parallelization features,model-based editing and visualization and many more [2]. Since AMALTHEA isAUTOSAR compliant it can be easily adapted into the automotive industry whenit comes to multi-core platform [3]. AMALTHEA system model is subdivided intoten models, each covering a specific aspect of the system under development [4]. In-formation in these models are basically similar to AUTOSAR but the level of detailcan be higher in AMALTHEA [4].

From the literature [2], [3] and [4] one can clearly see that AMALTHEA addressessome of the deficits of AUTOSAR, especially within the scope of multi-core.

3.3 Previous Work within the Project“EAST-ADL architecture description language describes a system on a higher levelof abstraction than AUTOSAR. Starting with a description of the features thathave to be developed, the model is refined until the level of abstraction coveredby AUTOSAR” [4]. The aim of this thesis is to reuse this already existing EAST-ADL/AUTOSAR models for the software components, and then use model trans-formation to transform them into AMALTHEA for precise timing analysis.

18

4Evaluation Criteria

After conducting the literature review, an evaluation criteria (list of capabilities)that the outcome of this thesis should address are framed and are as follows,

• Successful transformation of source architectural model to AMALTHEAmodel.

• Ability to verify response time for each task of the software component in amulti-core system.

• Ability to verify response time for each event-chain of the software componentin a multi-core system.

• Ability to measure the load distribution of tasks and runnables on the pro-cessing cores.

During the experimentation process, the results obtained from each iteration willbe compared against the above mentioned list of capabilities to ensure if it satisfiesall/some of the criteria.

19

4. Evaluation Criteria

20

5Methods

This thesis follows Action Research methodology as in Figure 5.1. Several iterationsof the research loop are carried out until an optimized plan/design choice is achieved,that is when the plan satisfies all/most of the evaluation criteria.

Figure 5.1: Action Research Loop

The steps followed in each iteration of the Action Research Loop are listed below,

Step 1 (Plan):Input: Thesis description (background, aim, problem statement, literature reviewand limitations), knowledge on AUTOSAR/EAST-ADL/AMALTHEA data mod-els, available model transformation tools/languages at AB Volvo and supportedtool suite for simulating/analyzing AMALTHEA models. Possibly the output ofstep 4 in each iteration will be an extra input to step 1 in the following iterations.

Activity: A preliminary plan on which architectural model type between EAST-ADL and AUTOSAR to be used (both EAST-ADL and AUTOSAR are not re-placements for one another and each serves a different purpose. AUTOSAR isthe standard implementation level model and EAST-ADL complements AUTOSARwith descriptions at a higher level of abstraction for support regarding variability,requirements, safety, etc.,), which example application to be used (Selection is basedon the available data rich application models within vehicle dynamics control depart-ment at AB Volvo), which model transformation tool to be used (the thesis intendsto use a tool that is developed by AB Volvo), which model transformation languageto be used (Selection is based on whether the transformation language is supportedby the selected transformation tool), which tool suite to be used for simulation and

21

5. Methods

analysis (Selection is based on whether the tool is open-source/commercial, level ofsupport to AMALTHEA data model, etc.,) are decided.

Output: A preliminary plan including an architectural model type, example appli-cation model, model transformation tool, transformation language, simulation andanalysis tool suite.

Step 2 (Act):Input: Architectural model type to be used, example application model to be used,tool suite to be used for model transformation, model transformation language tobe used, tool suite to be used for simulation and analysis.

Activity: The second step is to get ready all the necessary aspects such as ex-ample application, model transformation language and tool suites required for theengineering workflow as shown in Figure 1.1. The possible activities would be tomanually add details to the chosen example application model if it lacks some of thedetails which it supports and that can be mapped to AMALTHEA model duringmodel transformation. The guidelines for mapping will be framed and implementedin the model transformation language after a careful analysis of the meta modelsof both the source and target models. The activity also includes the preparation ofmodel transformation file.

Output: A working setup including an example application model, model transfor-mation tool, model transformation language, simulation and analysis tool.

Step 3 (Collect Results):Input: A working setup including an example application model, model transfor-mation language, model transformation tool, simulation and analysis tool.

Activity: The third step is to perform model transformation and simulation bytaking the role of an engineer as shown in Figure 1, and to collect results/outcomes.

Output: Results from the simulation and analysis activities.

Step 4 (Evaluate):Input: Evaluation criteria, results from the simulation and analysis activities.

Activity: In the final step, the results collected from the step 3 are comparedagainst the evaluation criteria (framed after conducting the literature review) to en-sure if it satisfies all/some of the criteria. Based on the evaluation, a new plan withpossible changes for improvement is created and the same cycle of steps is repeatedas shown in Figure 5.1.

22

5. Methods

Output: Decision on whether to stop the iteration or to start the next iterationwith a new plan. The output of this step is then an extra input to step 1 in thenext iteration.

The iteration continues until step 4 concludes that an optimized plan/design choiceis achieved, that is when the plan satisfies all/most of the evaluation criteria.

23

5. Methods

24

6Results

In this chapter, the results of each iteration of the action research loop are presented.

6.1 Results of each Iteration

6.1.1 Iteration 1:

Goal• Successful transformation of EAST-ADL model to AMALTHEA model.• Successful simulation and analysis of the resultant AMALTHEA model with

the help of a tool platform.

Step 1 (Plan)

Architectural Model Type

Since this thesis intends to experiment only with EAST-ADL and AUTOSAR archi-tectural models, during this iteration we select EAST-ADL architectural model forexperimentation. Both EAST-ADL and AUTOSAR are not replacements for oneanother, as each serves a different purpose.

Sample Application Model

The thesis intends to use the BBW EAST-ADL application model, that pre-existwithin vehicle dynamics control department at AB Volvo. The model is available inthe URL: http://www.east-adl.info/Specification/V2.1.12/EAST-ADL_V2.1.12.zip.

Model Transformation Tool

The thesis intends to use the AREAToP Technology Demonstrator tool developedby AB Volvo for model transformation.

XML Transformation Language

The thesis intends to use the XSLT Version 1.0 as the XML transformation language.This is because the AREAToP tool by AB Volvo has a built-in XSLT processor

25

http://www.east-adl.info/Specification/V2.1.12/EAST-ADL_V2.1.12.zip


6. Results

(Xalan-Java Version 2.7.1) that supports only XSLT Version 1.0 for transformingXML documents.

Simulation and Analysis Tool

This thesis focuses on two known tools that support AMALTHEA, namely Silexicaand Timing Architects. During this iteration, we pick Silexica tool platform forsimulation and analysis. A trial version (SLX-2018.10 sp-1) of the tool suite is usedfor the experiment.

Step 2 (Act)

Figure 6.1: Functional Design Architecture of BBW component in AREAToP

The FDA of the Brake-by-wire component is analyzed, to check if it lacks someof the details which it supports and that can be mapped to AMALTHEA modelduring model transformation. The thesis intends to focus only on the design levelabstraction layer of the EAST-ADL model. This is because the design level containsthe FDA, representing a full decomposition of functionalities denoted in the analysislevel with behavioral description. The Functional Design Architecture diagram ofthe Brake-by-wire component is shown in Figure 6.1.

26

6. Results

Table 6.1: Mapping between EAST-ADL and AMALTHEA elements duringModel Transformation

EAST-ADL AMALTHEA Remarks

FunctionModeling ::DesignFunctionPrototype

Task (Software Model) To avoid false positives during model transformation, De-signFunctionPrototype elements that satisfy the hierarchicalstructure “SYSTEM-MODEL/DESIGN-LEVEL/FUNCTIONAL-DESIGN-ARCHITECTURE” and with TYPE-TREF attributevalue matching either DESIGN-FUNCTION-TYPE or LOCAL-DEVICE-MANAGER are alone considered.

FunctionModeling ::DesignFunctionType

Runnable (SoftwareModel)

To avoid false positives during model transformation, Design-FunctionType elements with property IS-ELEMENTARY = trueare alone considered.

TimingConstraint ::PeriodicConstraint

Periodic Stimulus(Stimuli Model)

Nil

TimingConstraint ::PrecedenceConstraint

OrderPrecedenceSpec(Software Model ::Process Prototype)

Nil

TimingConstraint ::ExecutionTimeConstraint

Instructions Constant(Software Model ::Runnable)

Nil

HardwareModeling ::HardwareComponentPrototype

Processing Unit (Hard-ware Model)

To avoid false positives during model transformation, Hard-wareComponentPrototype elements with execution rate arealone considered. .

Events :: EventFunction Process Event (EventsModel)

Nil

Timing :: EventChain Event Chain (Con-straints Model)

Nil

TimingConstraints ::AgeConstraint

Event Chain LatencyConstraint (Con-straints Model)

Nil

After a careful analysis of the EAST-ADL and AMALTHEA models, the guidelinesfor mapping is framed as shown in Table 6.1. The guidelines for mapping areimplemented in the XSLT as shown in Listing A.1, and will take effect during themodel transformation process. Moreover, the Brake-by-wire EAST-ADL model lackssome details which it supports and that can be mapped to AMALTHEA model.This thesis uses AREAToP tool to edit the Brake-by-wire EAST-ADL model. Theadditional details added manually to the Brake-by-wire EAST-ADL model beforethe transformation process are listed below,

27

6. Results

Event Function Flow Port

Event Function Flow Port refers to the time when data is sent or received at theFunction Flow Port of a Function Prototype [6]. A function Flow Port refers toeither IN/OUT port of a Function Prototype. Figure 6.2 shows an Event FunctionFlow Port being added for theABS module in AREAToP.

Figure 6.2: Event Function Flow Port of ABS in AREAToP

Execution Time Constraint

An Execution Time Constraint is a timing constraint that limits the time betweenthe start and stop point of an executable function [6]. The start and stop pointrefer to the corresponding Event Function Flow Port of the executable function.The Execution Time Constraint does not count the intervals when the execution ofsuch an executable has been interrupted [6]. Figure 6.3 shows an Execution TimeConstraint being added for the ABS module in AREAToP.

Figure 6.3: Execution Time Constraint for ABS in AREAToP

Since the Execution Time Constraint elements in EAST-ADL model lack the ’value’property due to a flaw in AREAToP tool, the instruction count values are enteredin the ’Name’ property as a workaround.

Event Function

The Event Function refers to the invocation event of the function (when data isconsumed and execution starts) and may be data or time-related depending of trig-ger. The target function of an Event Function will be either a Function Type or aFunction Prototype [6]. Figure 6.4 shows an Event Function being added for theABS module in AREAToP.

28

6. Results

Figure 6.4: Event Function for ABS in AREAToP

Since the Event Function elements in EAST-ADL model lack the ’Event Type’property due to a flaw in AREAToP tool, the event type options are entered in the’Name’ property as a workaround.

Periodic Constraint

A Periodic Constraint is a timing constraint that describes a periodically occurringevent [6]. Figure 6.5 shows a Periodic Constraint being added for the ABS modulein AREAToP.

Figure 6.5: Periodic Constraint for ABS in AREAToP

Since the Periodic Constraint elements in EAST-ADL model lack the ’value’ prop-erty due to a flaw in AREAToP tool, the periodicity values are entered in the ’Name’property as a workaround.

Precedence Constraint

The Precedence Constraint represents a constraint applied on the execution sequenceof functional entities. For uni-directional functions without a precedence constraint,the functions will be executed according to their data dependencies. However, forbidirectional functions precedence constraint is mandatory [6]. Figure 6.6 showsa Precedence Constraint being added for the ABS and Brake Actuator module inAREAToP.

Figure 6.6: Precedence Constraint for ABS and Brake Actuator in AREAToP

29

6. Results

In each Precedence Constraint element of the EAST-ADL model, a successive en-tity is an immediate successor of the preceding entity. The preceding and successiveentities of each Precedence Constraint point to Design Function Prototype elementsrather Design Function Type elements.

Event Chain

An Event Chain is a container for two events, a stimulus event and a response eventthat must be causally related [6]. Figure 6.7 shows an Event Chain being added forABS module in AREAToP.

Figure 6.7: Event Chain for BBW in AREAToP

An event chain can have several sub event chains that are added as segments to theparent in sequence as in Figure 6.7.

Age Constraint

The Age Constraint defines how long before each response a corresponding stimulusmust have occurred. The Age Constraint is an alternative to the normal DelayConstraint for situations where the causal relation between event occurrences mustbe considered [6]. Figure 6.8 shows an Age constraint being added for an EventChain in the BBW model.

Figure 6.8: Age Constraint for BBW in AREAToP

Since the Age Constraint elements in EAST-ADL model lack the ’value’ propertydue to a flaw in AREAToP tool, the age values are entered in the ’Name’ propertyas a workaround.

Hardware Component Prototype

The Hardware Component Prototype represents an occurrence of a hardware ele-ment based on the type of the Hardware Component Prototype [6]. Figure 6.9 showsHardware Component Prototypes being added for ABS module in AREAToP.

30

6. Results

Figure 6.9: Hardware Component Prototypes of BBW in AREAToP

Preparing the XSLT file

Before starting the model transformation process, the transformation file (XSLTfile) is made ready by utilizing the available details supported by EAST-ADL modelwhich can be mapped to the AMALTHEA model. The details regarding the map-ping are explained in Table 6.1 and implemented in the XSLT file as in Listing A.1.

Some additional details that are not supported by EAST-ADL model, but requiredby AMALTHEA model for simulation are also added in the XSLT file as shown inListing A.1. During model transformation process these details get added to theresultant AMALTHEA model. The additional details are as follows,

1. Mapping Model• Details regarding the scheduler allocation, i.e., scheduler to processor core

mapping.• Details regarding the task allocation, i.e., task to scheduler mapping.• Details regarding the runnable allocation, i.e., runnable to scheduler map-

ping.

2. OS Model• Defining an operating system that can be either a generic operating sys-

tem or vendor specific operating system.• Defining a number of task schedulers within the defined operating system.• Defining a scheduling algorithm for each task schedulers defined.

3. Hardware Model• Defining a Hardware System with Instructions Per Cycle details.• Defining several ECUs within the defined hardware system.• Defining several micro-controller units for each ECU.

Step 3 (Collect Results)In this step, model transformation and simulation are performed.

Model Transformation Process

Once the transformation file is ready, the model transformation is carried out withthe help of AREAToP tool as shown in Figure 6.10. The XSLT code used in this

31

6. Results

transformation process is shown in Listing A.1. The outcome of this model trans-formation process would be an AMALTHEA model for Brake-by-wire componentwith a file extension “amxmi”. This file will be saved in the same directory as of theXSLT file.

(a) EAXML File Selection (b) XSLT File Selection

Figure 6.10: Model Transformation of EAST-ADL model in AREAToP

Editing AMALTHEA Model (Optional)

Figure 6.11: Editing AMALTHEA model in APP4MC

If necessary, before simulation the resultant AMALTHEA model can be editedgraphically by importing into the APP4MC tool as shown in Figure 6.11.

32

6. Results

Simulation and Analysis

The resultant AMALTHEA model is fed into the SLX tool platform for simulationand analysis. Once the model is imported SLX will convert the given AMALTHEAinput system model to SLX internal representation followed by the generation oftask graph as shown in Figure 6.12.

Figure 6.12: Task Graph for imported BBW in Silexica

The task graph displays all the tasks of the imported BBW model along with itsproperties like linked runnables, etc. Generating multi-core schedules is one of thekey features of the SLX tool chain. For each specified tasks in the system model,a multi-core schedule can be generated which allows the tasks to be distributed tomultiple processors. This task splitting mechanism can be applied to all or only asubset of processors of the target platform [10].

Figure 6.13: Scheduler Configuration Editor in SLX

33

6. Results

The Scheduler Configuration editor used to configure the creation of such schedulesis shown in Figure 6.13. Multi-core schedules of the runnables in each task areprovided via corresponding task specific Gantt charts as shown in Figure 6.14. Thegreen and red area in Figure 6.14 represents “running” and “idle” states of the tasksrespectively. SLX is not capable of generating a combined schedule for all tasks inthe system. Also, SLX does not provide any means to further analyze the simulationresults.

(a) ABS

(b) Global Brake Controller

Figure 6.14: Schedule for Tasks in SLX

Step 4 (Evaluate)

In this step, the results collected from step 3 are compared against the evaluationcriteria.

34

6. Results

Criterion 1: Successful transformation of source architectural model toAMALTHEA model

This criterion is satisfied by the current plan/iteration because the XSLT code inListing A.1 successfully transformed the BBWEAST-ADLmodel to BBWAMALTHEAmodel.

Criterion 2: Ability to verify response time for each task of the softwarecomponent in a multi-core system

This criterion is not satisfied by the current plan/iteration because the SLX tooldoes not support Stimuli Model in AMALTHEA, that is responsible to activateprocesses in a defined manner. Because of this several instances of the task cannotbe scheduled, which is one of the key factors to be considered while measuringresponse time.

Criterion 3: Ability to verify response time for each event-chain of thesoftware component in a multi-core system

This criterion is not satisfied by the current plan/iteration because the SLX tooldoes not support Event Model in AMALTHEA, that provide information aboutdifferent event entities that can be used for the modeling of event chains and forsome timing constraints.

Criterion 4: Ability to measure the load distribution of tasks and runnableson the processing cores

This criterion is not satisfied by the current plan/iteration because the SLX tooldoes not have the support to analyze load distribution of tasks and runnables onthe processing cores.

Thus it is clear from the evaluation results that the current plan/iteration has suc-ceeded in transforming the source architectural model to AMALTHEA model. How-ever, the SLX tool suite used in this iteration has only limited support in utilizingAMALTHEA model during simulation. Hence a new tool will be used for simulationin the next iteration.

6.1.2 Iteration 2:

Goal• Effective utilization of AMALTHEA model during simulation.

Step 1 (Plan)


During this iteration we select EAST-ADL architectural model for experimentation.

35

6. Results


The thesis intends to use the BBW EAST-ADL application model, that pre-existwithin vehicle dynamics control department at AB Volvo. The model is available inthe URL: http://www.east-adl.info/Specification/V2.1.12/EAST-ADL_V2.1.12.zip.




During this iteration, we continue to use XSLT Version 1.0 as the XML transforma-tion language.


During this iteration, we pick Timing Architects tool platform for simulation andanalysis as the Silexica tool in the previous iteration failed to effectively utilize theAMALTHEA model during simulation. A trial version (version 19.1) of the TA toolsuite is used for the experiment.

Step 2 (Act)No activity is performed in this step, i.e., the modified data rich Brake-by-wireEAST-ADL model and XSLT file from the previous iteration (Iteration 1) will bedirectly used in this iteration.

Step 3 (Collect Results)In this step, model transformation and simulation are performed.


No activity is done for performing model transformation, i.e., the resultant AMALTHEAmodel from the previous iteration (Iteration 1) will be directly used in this iteration.


The resultant BBW AMALTHEA model is fed into the TA tool suite platform forsimulation and analysis. Once the AMALTHEAmodel is imported, the TA tool suitewill analyze the model for any inconsistencies in the model through Validation Viewas in Figure 6.15. For example, the periodic tasks might be missing the recurrencetime value in the model.

36



6. Results

Figure 6.15: Validating AMALTHEA model in TA tool suite

Once the model is error free, simulation is started. The simulation results (schedul-ing of tasks) of the BBW model on a multi-core (triple-core) platform are visualizedvia gantt chart as shown in Figure 6.16. The grey and dark-green areas in Figure6.16 represents “activated” and “running” states of the tasks respectively. The blue,pink, red and green connections in Figure 6.16 represent different event chains inthe BBW model.

Figure 6.16: Simulation of BBW model in TA tool suite

The TA tool suite also provides means to analyze the simulation results via differentmetric tables. Figure 6.17 shows the response time requirements table for differenttasks in the BBW model. This requirements table contains details regarding re-quirement name, task name, response time value, fulfillment status, task occurrencecount and task severity level.

37

6. Results

Figure 6.17: Requirements table showing Response Time requirements for BBWmodel in TA tool suite

Figure 6.18 shows the event chain requirement table for the BBW model. This re-quirement table contains details regarding minimum duration, maximum duration,average duration and occurrence count of all event chains in the BBW model. How-ever, there is no information regarding the fulfillment status of the Event ChainLatency Requirement. Hence the user has to manually compare the latency require-ment values against maximum duration occurred to know the fulfillment status ofall event chains in the BBW model.

Figure 6.18: Event Chain Requirement table for BBW model in TA tool suite

Figure 6.19 shows the process table with task metrics for BBW model. The processtable contains details regarding task priority, deadline for tasks, net execution timeof tasks (time from the moment of start to termination of a task), maximum responsetime of tasks, maximum delay/lateness and CPU load (utilization) of each task ondifferent cores.

38

6. Results

Figure 6.19: Process table showing task metrics for BBW model in TA tool suite

Figure 6.20 shows the runnable table with runnable metrics for BBW model. Therunnable table contains details regarding minimum and maximum gross executiontime (time from the moment of activation to termination of a runnable), minimumand maximum net execution time (time from the moment of start to termination ofa runnable) and CPU load (utilization) of each runnable on different cores.

Figure 6.20: Runnable table showing runnable metrics for BBW model in TAtool suite

Figure 6.21 shows the hardware resource table with CPU metrics for BBW model.The hardware resource table contains details regarding CPU running and Idle per-centage for different cores.

Figure 6.21: Hardware Resource table showing CPU metrics for BBW model inTA tool suite

39

6. Results

Step 4 (Evaluate)In this step, the results collected from step 3 are compared against the evaluationcriteria.


This criterion is satisfied by the current plan/iteration because the XSLT code inListing A.1 successfully transformed the BBWEAST-ADLmodel to BBWAMALTHEAmodel.


This criterion is satisfied by the current plan/iteration, which is evident from theFigure 6.17.




This criterion is satisfied by the current plan/iteration, which is evident from theFigures 6.19 and 6.20.

Thus it is clear from the evaluation results that TA tool suite has effectively utilizedAMALTHEA model during simulation. Hence it is concluded that an optimizedplan is achieved since the plan satisfies all of the evaluation criteria. However, thethesis also intends to experiment with AUTOSAR model in the next iteration.

6.1.3 Iteration 3:

Goal• Successful transformation of AUTOSAR model to AMALTHEA model.

Step 1 (Plan)


During this iteration we select AUTOSAR architectural model for experimentation.

40

6. Results


The thesis intends to use the BBW AUTOSAR application model that will becreated during the “Act” phase of this iteration and does not pre-exist within ABVolvo. The created model is available in Listing A.3.




During this iteration, we continue to use XSLT Version 1.0 as the XML transforma-tion language.


During this iteration, we continue to use the Timing Architects tool platform sinceit effectively utilized the AMALTHEA model during simulation.

Step 2 (Act)

Figure 6.22: AUTOSAR model of BBW in AREAToP

In this step, the AUTOSAR model for BBW component is developed from scratch.The thesis intends to use the AREAToP Technology Demonstrator tool developedby AB Volvo for creating the AUTOSAR model. The complete model is available in

41

6. Results

Listing A.3, which contains details regarding runnables, tasks, stimulus, executionorder, execution time, processing cores, events, event chains and timing constraintsas in Figure 6.22.

After a careful analysis of the AUTOSAR and AMALTHEA models, the guidelinesfor mapping is framed as shown in Table 6.2. The guidelines for mapping areimplemented in the XSLT as shown in Listing A.2, and will take effect during themodel transformation process. Since the BBW AUTOSAR model is developed fromscratch, all the details that it supports and that can be mapped to AMALTHEAmodel are added during the development process itself.

Table 6.2: Mapping between AUTOSAR and AMALTHEA elements duringModel Transformation

AUTOSAR AMALTHEA

SwComponentPrototype Task (Software Model)

AtomicSwComponentType :: RunnableEntity Runnable (Software Model)

Event TriggeringConstraint :: PeriodicEventTriggering Periodic Stimulus (Stimuli Model)

TimingConstraint :: ExecutionOrderConstraint OrderPrecedenceSpec (Software Model ::Process Prototype)

TimingConstraint :: ExecutionTimeConstraint Instructions Constant (Software Model :: Runnable)

HwDescriptionEntity :: HwElement Processing Unit (Hardware Model)

TimingDescriptionEvent :: TDEventSwcInternalBehavior Process Event (Events Model)

TimingDescription :: TimingDescriptionEventChain Event Chain (Constraints Model)

TimingConstraint :: LatencyTimingConstraint Event Chain Latency Constraint (Constraints Model)

Preparing the XSLT file

Before starting the model transformation process, the transformation file (XSLTfile) is made ready by utilizing the available details supported by AUTOSAR modelwhich can be mapped to the AMALTHEA model. The details regarding the map-ping are explained in Table 6.2 and implemented in the XSLT file as in Listing A.2.

Some additional details that are not supported by AUTOSAR model, but requiredby AMALTHEA model for simulation are also added in the XSLT file as shown inListing A.2. During model transformation process these details get added to the

42

6. Results

resultant AMALTHEA model. The additional details are as follows,

1. OS Model• Defining a number of task schedulers within the defined operating system.• Defining a scheduling algorithm for each task schedulers defined.

2. Mapping Model• Details regarding the scheduler allocation, i.e., scheduler to processor core

mapping.• Details regarding the task allocation, i.e., task to scheduler mapping.• Details regarding the runnable allocation, i.e., runnable to scheduler map-

ping.

Step 3 (Collect Results)

In this step, model transformation and simulation are performed.


Once the transformation file is ready, the model transformation is carried out withthe help of AREAToP tool as shown in Figure 6.23. The XSLT code used in thistransformation process is shown in Listing A.2. The outcome of this model trans-formation process would be an AMALTHEA model for Brake-by-wire componentwith a file extension “amxmi”. This file will be saved in the same directory as of theXSLT file.

(a) ARXML File Selection (b) XSLT File Selection

Figure 6.23: Model Transformation of AUTOSAR model in AREAToP

43

6. Results


No activity is done for simulation and analysis because for simplicity the thesisintends to have a single AMALTHEA model for BBW component that can be sim-ulated and analyzed, i.e., the AMALTHEA model obtained by model transformingBBW EAST-ADL model will be an exact copy of the AMALTHEA model obtainedby model transforming BBW AUTOSAR model. In general, this would not bethe case. Thus the simulation and analysis results will be the same as of previousiteration (Iteration 2).

Step 4 (Evaluate)In this step, the results collected from step 3 are compared against the evaluationcriteria.


This criterion is satisfied by the current plan/iteration because the XSLT code inListing A.2 successfully transformed the BBWAUTOSARmodel to BBWAMALTHEAmodel.






This criterion is satisfied by the current plan/iteration, which is evident from theFigures 6.19 and 6.20.

Thus it is clear from the evaluation results that the AUTOSAR model has beensuccessfully model transformed to AMALTHEA model and the TA tool suite haseffectively utilized the resultant AMALTHEA model during simulation. With nofurther plans in experimenting with architectural models apart from EAST-ADLand AUTOSAR, the iteration is stopped.

44

45

7. Discussion

7Discussion

7.1 Comparison of the effort to extend the EAST-ADL and AUTOSARmodels to AMALTHEA

Table 7.1: Comparison of model elements covered by AUTOSAR, AMALTHEAand EAST-ADL

Concept AUTOSAR AMALTHEA EAST-ADL

Hardware Model• ECUs, cores, memories, peripherals

YES YES PARTLY

Operating System Model• Abstract OS description• Task schedulers• Scheduling algorithm

PARTLY YES NO

Dynamic Software Architecture• Stimuli (Activation pattern)• Function runtimes• Complex call graph

PARTLY YES PARTLY

Mapping• Scheduler to processor core mapping• Task to scheduler mapping• Runnable to scheduler mapping

PARTLY YES NO

Timing Requirements• Task deadlines• Response Time• Events and Event Chain requirements• Periodicity

YES YES YES

Software Design Constraints• Execution Order Constraint• Data Age Constraint• Data Coherency Groups• Affinity Constraints

YES YES PARTLY

Static Software Architecture• Software component description• Function and data definitions• Communication interfaces

YES YES YES

46

7. Discussion

In this thesis, comparison towards the effort made to extend the EAST-ADL andAUTOSAR model into AMALTHEA is very basic, i.e., the comparison will only beon the model elements that are mandatory for simulating an AMALTHEA model.Based on Table 6.1, 6.2 and Table 7.1, it is clear that AUTOSAR has a closeresemblance to AMALTHEA compared to EAST-ADL. Thus it is concluded thatthe effort needed to extend the EAST-ADL model is more than the effort to extendthe AUTOSAR model

7.2 Engineering Work Flow

Optimized Plan

Figure 7.1: Optimized Plan

From the results of each iteration of the action research loop in the previous chapter,it was clear that an optimized plan/design choice as in Figure 7.1 was reached inIteration 2, as the plan satisfied all of the evaluation criteria. This optimized plancan be integrated into a work flow as shown in Figure 7.2.

Figure 7.2: Engineering Work Flow Loop

This work flow will be beneficial for embedded engineers in taking timing-aware de-sign decisions during the software development process. The engineers can perform

47

7. Discussion

several iterations of the engineering work flow loop with possible changes in tim-ing properties, scheduling design, etc., based on the feedback obtained from everyiteration, until all the timing requirements are met.

Merits and Demerits• This approach of transforming the existing architectural models to AMALTHEA

model will save plenty of development time spent on creating a new AMALTHEAmodel from scratch, thus increasing the productivity. Incorporating automatedmodel transformation via XSLT scripts rather manual model transformationalso aids in reducing the development time.

• One disadvantage with the model transformation script used in this thesis isthat it can generate only a basic AMALTHEA model comprising of only themandatory model elements necessary for simulation. In order to add additionaldetails, the developer has to manually add the details to the AMALTHEAmodel using APP4MC tool as shown in Subsection 6.1.1.

7.3 Limitations in Simulation/Analysis Tool Plat-form

The tool platforms used in this thesis for simulating/analyzing AMALTHEA modelshave certain limitations as discussed below,

Limitations in Silexica Tool Platform

Figure 7.3: Platform Models Supported by Silexica Tool [10]

• The current version, SLX-2018.10 sp-1 of the tool supports only AMALTHEAxml-schema-definition version 0.8.2. A single Software Model that will con-tain all the task, runnable and variable information is required for importing

48

7. Discussion

[10]. Meanwhile, current xml-schema-definition supported by AMALTHEA isversion 0.9.4.

• When importing an AMALTHEA model, the tool only supports a model withHardware Model that matches one of the many platform models supported bythe SLX tool as shown in Figure 7.3. The criteria for a matching model arethat the number of cores and the core names match those given in an SLXplatform model.

• The current version, SLX-2018.10 sp-1 of the tool does not support StimuliModel in AMALTHEA, that contains stimulus and clock objects. A stimulusis responsible to activate a task/process.

• The current version, SLX-2018.10 sp-1 of the tool does not support ConstraintsModel in AMALTHEA, that provide information about the different kind ofconstraints that has to be satisfied during execution.

• The current version, SLX-2018.10 sp-1 of the tool does not support EventModel in AMALTHEA, that provide information about different event enti-ties that can be used for the modeling of event chains and for some timingconstraints.

Limitations in TA Tool Platform

Figure 7.4: Supported Processor Models for TA Tool Suite [11]

49

7. Discussion

• Currently available processor models in TA tool suite are shown in Figure7.4, but the tool suite also allows the integration of supplier specific processormodels depending upon the software license issued [11].

• Currently supported operating system models by TA tool suite are MICROSA-OS, Tresos AutoCore and Tresos Safety OS [11].

• Current version of TA tool suite (version 19.1.0) supports only AMALTHEAxml-schema-definition version 0.9.2. Meanwhile current xml-schema-definitionsupported by AMALTHEA is version 0.9.4.

7.4 Possible Future Work• The AMALTHEA model, modelled in this thesis is primary, which contains the

basic information necessary for simulation. In future, a complete AMALTHEAmodel utilizing all the features that it supports can be modelled (by extendingthe model transformation script) and simulated.

• The thesis focused only on the verification of the timing behavior of applica-tion software. Further research into optimization of software distribution onprocessing cores can be conducted.

50

8Conclusion

The work presented in this thesis describes a timing-aware model-driven method-ology for software development, with a special focus on embedded multi-core sys-tems. The thesis gives an overview of three modelling approaches, namely EAST-ADL, AUTOSAR and AMALTHEA which are commonly used within the scope ofmulti-core automotive software development. By going into detail and comparingthese models with respect to their meta models, methodologies and implementa-tions, the thesis was able to identify similarities and differences between these mod-els. The thesis also proposed and succeeded in model transforming the existingEAST-ADL/AUTOSAR model to AMALTHEA model, which provides extendedsupport for multi-core timing verification. Several iterations of the methodology arecarried out with possible changes in the design plan, and an optimized design ispicked based on evaluation criteria. Considering the implementation alternatives,a model transformation would be harder without automated support. The thesissolved this problem by introducing an automated model transformation via XSLT.Finally, the thesis leverages the generated AMALTHEA model for model-based pre-cise timing verification with the help of supported simulation/analysis tools. ThoughAMALTHEA is recent to the automotive industry, the development support fromcorporates and its open source license makes it an aspiring approach for modellingthe future complex multi-core ECU architectures. The outcome of this thesis willbe beneficial for embedded engineers in taking timing-aware design decisions duringthe development cycle.

51

8. Conclusion

52

Bibliography

[1] Bucaioni, A., Addazi, L., Cicchetti, A., Ciccozzi, F., Eramo, R., Mubeen, S.and Sjödin, M., 2018. MoVES: A Model-Driven Methodology for VehicularEmbedded Systems. IEEE Access, 6, pp.6424-6445.

[2] Höttger, R., Mackamul, H., Sailer, A., Steghöfer, J.P. and Tessmer, J., 2017.APP4MC: Application platform project for multi-and many-core systems.it-Information Technology, 59(5), pp.243-251.

[3] Höttger, R., Lauschner, U., Närdemann, P., Heisig, P., Wolff, C., Kamsties,E. and Igel, B., Teaching distributed and parallel systems with APP4MC.In International Symposium on Embedded Systems and Trends in TeachingEngineering (pp. 126-134).

[4] Sailer, A., Schmidhuber, S., Hempe, M., Deubzer, M. and Mottok, J., 2016,April. Distributed Multi-Core Development in the Automotive Domain-APractical Comparison of ASAM MDX vs. AUTOSAR vs. AMALTHEA. InARCS 2016; 29th International Conference on Architecture of ComputingSystems (pp. 1-8). VDE.

[5] AMALTHEA4public consortium, “APP4MC help documentation”, 2019.[Online]. Available: https://www.eclipse.org/app4mc/documentation/.

[6] EAST-ADL Domain Model Specification version V2.1.12. [Online].Available: http://www.east-adl.info/Specification/V2.1.12/EAST-ADL-Specification_V2.1.12.pdf

[7] Cuenot, P., Frey, P., Johansson, R., Lönn, H., Papadopoulos, Y., Reiser, M.O.,Sandberg, A., Servat, D., Kolagari, R.T., Törngren, M. and Weber, M., 2007,November. 11 the east-adl architecture description language for automotiveembedded software. In Dagstuhl Workshop on Model-Based Engineering ofEmbedded Real-Time Systems (pp. 297-307). Springer, Berlin, Heidelberg.

[8] Qureshi, T.N., Chen, D., Lönn, H. and Törngren, M., 2011, September.From EAST-ADL to AUTOSAR software architecture: a mapping scheme. InEuropean Conference on Software Architecture (pp. 328-335). Springer, Berlin,Heidelberg.

53

https://www.eclipse.org/app4mc/documentation/.

http://www.east-adl.info/Specification/V2.1.12/EAST-ADL-Specification_V2.1.12.pdf

http://www.east-adl.info/Specification/V2.1.12/EAST-ADL-Specification_V2.1.12.pdf

Bibliography

[9] Wikipedia contributors. (2018, October 7). EAST-ADL. In Wikipedia,The Free Encyclopedia. Retrieved 20:31, May 1, 2019, from https://en.wikipedia.org/w/index.php?title=EAST-ADL&oldid=862836615

[10] SILEXICA, [Online]: https://www.silexica.com/

[11] VECTOR, “TA Tool Suite” [Online]: https://www.vector.com/int/en/products/products-a-z/software/ta-tool-suite/

[12] Wikipedia contributors. (2019, March 25). XML transformation language.In Wikipedia, The Free Encyclopedia. Retrieved 14:02, May 20, 2019, fromhttps://en.wikipedia.org/w/index.php?title=XML_transformation_language&oldid=889470678

[13] Wikipedia contributors. (2019, May 15). XSLT. In Wikipedia, TheFree Encyclopedia. Retrieved 15:04, May 20, 2019, from https://en.wikipedia.org/w/index.php?title=XSLT&oldid=897247948

[14] W3schools, [Online]: https://www.w3schools.com/xml/xsl_intro.asp

[15] AUTOSAR, Software Component Template, [Online]: https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_TPS_SoftwareComponentTemplate.pdf

[16] The AUTOSAR Consortium, [Online]: https://www.autosar.org/

[17] AUTOSAR, Layered Software Architecture, [Online]: https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf

[18] EATOP Project, [Online]: https://www.eclipse.org/eatop/

[19] Artop Project, [Online]: https://www.artop.org/

[20] embitel, [Online]: https://www.embitel.com/blog/embedded-blog/decoding-the-component-concept-of-the-application-layer-in-autosar

[21] SCHEID Automotive, [Online]: https://automotive.wiki/index.php/Interface

[22] Mubeen, S., Nolte, T., Sjödin, M., Lundbäck, J. and Lundbäck, K.L., 2019.Supporting timing analysis of vehicular embedded systems through the refine-ment of timing constraints. Software Systems Modeling, 18(1), pp.39-69.

54

https://en.wikipedia.org/w/index.php?title=EAST-ADL&oldid=862836615

https://en.wikipedia.org/w/index.php?title=EAST-ADL&oldid=862836615

https://www.silexica.com/

https://www.vector.com/int/en/products/products-a-z/software/ta-tool-suite/

https://www.vector.com/int/en/products/products-a-z/software/ta-tool-suite/

https://en.wikipedia.org/w/index.php?title=XML_transformation_language&oldid=889470678

https://en.wikipedia.org/w/index.php?title=XML_transformation_language&oldid=889470678

https://en.wikipedia.org/w/index.php?title=XSLT&oldid=897247948

https://en.wikipedia.org/w/index.php?title=XSLT&oldid=897247948

https://www.w3schools.com/xml/xsl_intro.asp

https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_TPS_SoftwareComponentTemplate.pdf



https://www.autosar.org/

https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf



https://www.eclipse.org/eatop/

https://www.artop.org/

https://www.embitel.com/blog/embedded-blog/decoding-the-component-concept-of-the-application-layer-in-autosar

https://www.embitel.com/blog/embedded-blog/decoding-the-component-concept-of-the-application-layer-in-autosar

https://automotive.wiki/index.php/Interface

https://automotive.wiki/index.php/Interface

AAppendix 1

A.1 Code Snippet

Listing A.1: XSLT code for transforming EAST-ADL to AMALTHEA model12 <?xml v e r s i o n=" 1 .0 " encoding="UTF−8" ?>3 <!−− x s l s t y l e s h e e t d e c l a r a t i o n −−>4 <x s l : s t y l e s h e e t x m l n s : x s l=" h t t p : //www. w3 . org /1999/XSL/Transform " xmlns:ea=" h t t p : //

east−adl . i n f o / 2 . 1 . 1 2 " x m l n s : e x s l t=" h t t p : // e x s l t . org /common" v e r s i o n=" 1 .0 "extens ion−e lement−pre f ixes=" e x s l t ">

5 <x s l : o u t p u t method=" xml " indent=" yes " />6 <x s l : k e y name=" orderPrecedence " match=" orderPrecedenceSpec " use=" @or ig in " />7 <x s l : k e y name=" ins t ruct ion_count " match="ea:EXECUTION−TIME−CONSTRAINT" use="

ea:NAME" />8 <!−− This template i s used to e x t r a c t a sub−str ing with in a s t r i n g a f t e r the l a s t

occurence o f the d e l i m i t e r ' / ' −−>9 <x s l : t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">

10 <xsl :param name=" s t r i n g " />11 <xsl :param name=" d e l i m i t e r " />12 <x s l : c h o o s e>13 <xsl :when t e s t=" conta in s ($ s t r i n g , $ d e l i m i t e r ) ">14 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">15 <xsl:with−param name=" s t r i n g " s e l e c t=" s u b s t r i n g − a f t e r ($ s t r i n g , $ d e l i m i t e r

) " />16 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" $ d e l i m i t e r " />17 </ x s l : c a l l − t e m p l a t e>18 </ xs l :when>19 <x s l : o t h e r w i s e>20 <x s l : v a l u e − o f s e l e c t=" $ s t r i n g " />21 </ x s l : o t h e r w i s e>22 </ x s l : c h o o s e>23 </ x s l : t e m p l a t e>24 <!−− This template i s used to get the proce s sProto types −−>25 <x s l : t e m p l a t e name=" get_processPrototypes ">26 <!−− Here we are load ing some nodes to a v a r i a b l e to get a Result Tree Fragment

−−>27 <x s l : v a r i a b l e name="RTF">28 <x s l : f o r − e a c h s e l e c t=" //ea:PRECEDENCE−CONSTRAINT">29 <x s l : v a r i a b l e name=" preceding_task ">30 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">31 <xsl:with−param name=" s t r i n g " s e l e c t=" . /ea:PRECEDING−IREF/

ea:FUNCTION−PROTOTYPE−TARGET−REF" />32 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />33 </ x s l : c a l l − t e m p l a t e>34 </ x s l : v a r i a b l e>35 <x s l : v a r i a b l e name=" s u cc e s s i ve _ ta sk ">36 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">37 <xsl:with−param name=" s t r i n g " s e l e c t=" . / ea:SUCCESSIVE−IREF/

ea:FUNCTION−PROTOTYPE−TARGET−REF" />38 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />39 </ x s l : c a l l − t e m p l a t e>40 </ x s l : v a r i a b l e>41 <x s l : v a r i a b l e name=" preceding_runnable ">42 <x s l : c a l l − t e m p l a t e name=" get−preceding−success ive−runnables ">

I

A. Appendix 1

43 <xsl:with−param name=" funct ionPrototype " s e l e c t=" $ preceding_task " />44 </ x s l : c a l l − t e m p l a t e>45 </ x s l : v a r i a b l e>46 <x s l : v a r i a b l e name=" succes s ive_runnab le ">47 <x s l : c a l l − t e m p l a t e name=" get−preceding−success ive−runnables ">48 <xsl:with−param name=" funct ionPrototype " s e l e c t=" $ su c ce s s i v e_ ta s k " />49 </ x s l : c a l l − t e m p l a t e>50 </ x s l : v a r i a b l e>51 <orderPrecedenceSpec o r i g i n=" { concat ($ preceding_runnable , '? type=Runnable ' )

} " t a r g e t=" { concat ($ success ive_runnable , '? type=Runnable ' ) } " orderType="d i r ec tOrder " />

52 </ x s l : f o r − e a c h>53 </ x s l : v a r i a b l e>54 <!−− Now we take the RTF and convert i t to a node−set so we can p r o c e s s i t yet

again ! −−>55 <x s l : v a r i a b l e name="set_RTF" s e l e c t=" e x s l t : n o d e − s e t ($RTF) " />56 <proces sPrototypes name=" ">57 <!−− Go and play with the new s e t −−>58 <x s l : f o r − e a c h s e l e c t=" $set_RTF/ orderPrecedenceSpec [ generate− id ( . ) =

generate− id ( key ( ' orderPrecedence ' , @or ig in ) [ 1 ] ) ] ">59 <xs l : copy−o f s e l e c t=" . " />60 </ x s l : f o r − e a c h>61 </ proce s sPrototypes>62 </ x s l : t e m p l a t e>63 <!−− This template i s used to get the s t i m u l i name −−>64 <x s l : t e m p l a t e name=" get−stimuli−name ">65 <xsl :param name=" taskName " />66 <x s l : f o r − e a c h s e l e c t=" //ea:EVENT−FUNCTION/ea:FUNCTION−IREF/

ea:FUNCTION−PROTOTYPE−TARGET−REF">67 <x s l : v a r i a b l e name=" EventFunctionName " s e l e c t=" . . / . . / ea:SHORT−NAME" />68 <x s l : v a r i a b l e name=" Var2 ">69 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">70 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />71 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />72 </ x s l : c a l l − t e m p l a t e>73 </ x s l : v a r i a b l e>74 <!−− <varoutput>75 <x s l : v a l u e − o f s e l e c t=" $Var2 " />76 </ varoutput> −−>77 < x s l : i f t e s t=" $taskName = $Var2 ">78 <x s l : f o r − e a c h s e l e c t=" //ea:PERIODIC−CONSTRAINT/ea:EVENT−REF">79 <x s l : v a r i a b l e name=" Var3 ">80 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">81 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />82 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />83 </ x s l : c a l l − t e m p l a t e>84 </ x s l : v a r i a b l e>85 < x s l : i f t e s t=" $Var3 = $EventFunctionName ">86 <x s l : v a l u e − o f s e l e c t=" concat ( . . / ea:SHORT−NAME, '? type=Per iod icSt imulus

' ) " />87 </ x s l : i f>88 </ x s l : f o r − e a c h>89 </ x s l : i f>90 </ x s l : f o r − e a c h>91 </ x s l : t e m p l a t e>92 <!−− This template i s used to get the i n s t r u c t i o n count f o r each runnable −−>93 <x s l : t e m p l a t e name=" get− instruct ion−count ">94 <xsl :param name=" runnableName " />95 <x s l : f o r − e a c h s e l e c t=" //ea:DESIGN−FUNCTION−PROTOTYPE/ea:TYPE−TREF[@TYPE='

DESIGN−FUNCTION−TYPE' ] | //ea:DESIGN−FUNCTION−PROTOTYPE/ea:TYPE−TREF[@TYPE='LOCAL−DEVICE−MANAGER' ] ">

96 <x s l : v a r i a b l e name=" Var4 ">97 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">98 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />99 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />

100 </ x s l : c a l l − t e m p l a t e>101 </ x s l : v a r i a b l e>102 < x s l : i f t e s t=" $runnableName = $Var4 ">103 <x s l : v a r i a b l e name=" prototypeName " s e l e c t=" . . /ea:SHORT−NAME" />104 <x s l : f o r − e a c h s e l e c t=" //ea:EVENT−FUNCTION−FLOW−PORT/ea:PORT−IREF/

II

A. Appendix 1

ea:FUNCTION−PROTOTYPE−REF">105 <x s l : v a r i a b l e name=" Var5 ">106 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">107 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />108 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />109 </ x s l : c a l l − t e m p l a t e>110 </ x s l : v a r i a b l e>111 < x s l : i f t e s t=" $prototypeName = $Var5 ">112 <x s l : v a r i a b l e name=" functionFlowPortName " s e l e c t=" . . / . . / ea:SHORT−NAME"

/>113 <x s l : f o r − e a c h s e l e c t=" //ea:EXECUTION−TIME−CONSTRAINT[ generate− id ( ) =

generate− id ( key ( ' ins t ruct ion_count ' , ea:NAME) [ 1 ] ) ] ">114 <x s l : v a r i a b l e name=" Var6 ">115 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">116 <xsl:with−param name=" s t r i n g " s e l e c t="ea:START−REF" />117 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />118 </ x s l : c a l l − t e m p l a t e>119 </ x s l : v a r i a b l e>120 < x s l : i f t e s t=" $ functionFlowPortName = $Var6 ">121 <x s l : v a l u e − o f s e l e c t="ea:NAME" />122 </ x s l : i f>123 </ x s l : f o r − e a c h>124 </ x s l : i f>125 </ x s l : f o r − e a c h>126 </ x s l : i f>127 </ x s l : f o r − e a c h>128 </ x s l : t e m p l a t e>129 <!−− This template i s used to r e s o l v e the precedence c o n t r a i n t s −−>130 <x s l : t e m p l a t e name=" get−preceding−success ive−runnables ">131 <xsl :param name=" funct ionPrototype " />132 <x s l : f o r − e a c h s e l e c t=" //ea:SYSTEM−MODEL[ 1 ] / ea:DESIGN−LEVEL [ 1 ] /

ea:FUNCTIONAL−DESIGN−ARCHITECTURE[ 1 ] / ea:TYPE−TREF [ 1 ] [@TYPE='DESIGN−FUNCTION−TYPE' ] ">

133 <x s l : v a r i a b l e name="myVar">134 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">135 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />136 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />137 </ x s l : c a l l − t e m p l a t e>138 </ x s l : v a r i a b l e>139 <x s l : f o r − e a c h s e l e c t=" //ea:DESIGN−FUNCTION−PROTOTYPE[

ancestor::ea:DESIGN−FUNCTION−TYPE [ea:SHORT−NAME= $myVar ] ] / ea:TYPE−TREF[@TYPE='DESIGN−FUNCTION−TYPE' ] | //ea:DESIGN−FUNCTION−PROTOTYPE[ancestor::ea:DESIGN−FUNCTION−TYPE [ea:SHORT−NAME=$myVar ] ] / ea:TYPE−TREF[@TYPE='LOCAL−DEVICE−MANAGER' ] ">

140 <x s l : v a r i a b l e name=" taskName " s e l e c t=" . . /ea:SHORT−NAME" />141 < x s l : i f t e s t=" $ funct ionPrototype = $taskName ">142 <x s l : v a r i a b l e name=" Var7 ">143 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">144 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />145 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />146 </ x s l : c a l l − t e m p l a t e>147 </ x s l : v a r i a b l e>148 <varoutput>149 <x s l : v a l u e − o f s e l e c t=" $Var7 " />150 </ varoutput>151 </ x s l : i f>152 </ x s l : f o r − e a c h>153 </ x s l : f o r − e a c h>154 </ x s l : t e m p l a t e>155 <!−− x s l template d e c l a r a t i o n :156 template t e l l s the x l s t p r o c e s s o r about which s e c t i o n o f xml157 document to be formatted . I t takes an XPath e x p r e s s i o n .158 In our case , i t i s matching root element −−>159 <x s l : t e m p l a t e match=" / ">160 <!−− New Line −−>161 <x s l : t e x t />162 <am:Amalthea xmlns:am=" h t t p : //app4mc . e c l i p s e . org / amalthea / 0 . 9 . 2 " xmlns:xmi="

h t t p : //www. omg . org /XMI" x m l n s : x s i=" h t t p : //www. w3 . org /2001/XMLSchema−instance "x m i : v e r s i o n=" 2 .0 ">

163 <swModel>

III

A. Appendix 1

164 <x s l : f o r − e a c h s e l e c t=" //ea:SYSTEM−MODEL[ 1 ] / ea:DESIGN−LEVEL [ 1 ] /ea:FUNCTIONAL−DESIGN−ARCHITECTURE[ 1 ] / ea:TYPE−TREF [ 1 ] [@TYPE='DESIGN−FUNCTION−TYPE' ] ">

165 <!−− <varoutput>166 <x s l : v a l u e − o f s e l e c t=" $myVar" />167 </ varoutput> −−>168 <x s l : v a r i a b l e name="myVar">169 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">170 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />171 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />172 </ x s l : c a l l − t e m p l a t e>173 </ x s l : v a r i a b l e>174 <x s l : f o r − e a c h s e l e c t=" //ea:DESIGN−FUNCTION−PROTOTYPE[

ancestor::ea:DESIGN−FUNCTION−TYPE [ea:SHORT−NAME= $myVar ] ] / ea:TYPE−TREF[@TYPE='DESIGN−FUNCTION−TYPE' ] | //ea:DESIGN−FUNCTION−PROTOTYPE[ancestor::ea:DESIGN−FUNCTION−TYPE [ea:SHORT−NAME=$myVar ] ] / ea:TYPE−TREF[@TYPE='LOCAL−DEVICE−MANAGER' ] ">

175 <x s l : v a r i a b l e name=" taskName " s e l e c t=" . . /ea:SHORT−NAME" />176 <x s l : v a r i a b l e name=" Var1 ">177 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">178 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />179 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />180 </ x s l : c a l l − t e m p l a t e>181 </ x s l : v a r i a b l e>182 <x s l : v a r i a b l e name=" r e f 1 ">183 <x s l : v a l u e − o f s e l e c t=" concat ($ Var1 , '? type=Runnable ' ) " />184 </ x s l : v a r i a b l e>185 <x s l : v a r i a b l e name=" call_seq_name ">186 <x s l : v a l u e − o f s e l e c t=" concat ( 'CS_' , $ taskName ) " />187 </ x s l : v a r i a b l e>188 <x s l : v a r i a b l e name=" r e f 2 ">189 <x s l : c a l l − t e m p l a t e name=" get−stimuli−name ">190 <xsl:with−param name=" taskName " s e l e c t=" $taskName " />191 </ x s l : c a l l − t e m p l a t e>192 </ x s l : v a r i a b l e>193 <ta s ks name=" {$taskName} " s t i m u l i=" {$ r e f 2 } " preemption=" preemptive "

mult ip l eTaskAct ivat ionLimit=" 1 ">194 <cal lGraph>195 <graphEntr i e s x s i : t y p e=" am:CallSequence " name=" {$ call_seq_name} ">196 <c a l l s x s i : t y p e=" am:TaskRunnableCall " runnable=" {$ r e f 1 } " />197 </ graphEntr i e s>198 </ cal lGraph>199 </ t as k s>200 </ x s l : f o r − e a c h>201 </ x s l : f o r − e a c h>202 <x s l : f o r − e a c h s e l e c t=" //ea:DESIGN−FUNCTION−TYPE[ea:IS−ELEMENTARY = ' true ' ]

| //ea:LOCAL−DEVICE−MANAGER[ea:IS−ELEMENTARY = ' true ' ] ">203 <x s l : v a r i a b l e name=" runnableName " s e l e c t="ea:SHORT−NAME" />204 <x s l : v a r i a b l e name=" r e f 3 ">205 <x s l : c a l l − t e m p l a t e name=" get− instruct ion−count ">206 <xsl:with−param name=" runnableName " s e l e c t=" $runnableName " />207 </ x s l : c a l l − t e m p l a t e>208 </ x s l : v a r i a b l e>209 <runnables name=" {$runnableName} " c a l l b a c k=" f a l s e " s e r v i c e=" f a l s e ">210 <runnableItems x s i : t y p e=" am:ExecutionNeed ">211 <d e f a u l t key=" I n s t r u c t i o n s ">212 <value x s i : t y p e=" am:NeedConstant " va lue=" {$ r e f 3 } " />213 </ d e f a u l t>214 </ runnableItems>215 </ runnables>216 </ x s l : f o r − e a c h>217 <x s l : c a l l − t e m p l a t e name=" get_processPrototypes " />218 </swModel>219 <hwModel>220 <d e f i n i t i o n s x s i : t y p e=" am:Proce s s ingUn i tDe f in i t i on " name="CPU0_type" puType

="CPU" f e a t u r e s=" I n s t r u c t i o n s /IPC_1 . 0 ? type=HwFeature " />221 <d e f i n i t i o n s x s i : t y p e=" am:Proce s s ingUn i tDe f in i t i on " name="CPU1_type" puType


="CPU" f e a t u r e s=" I n s t r u c t i o n s /IPC_1 . 0 ? type=HwFeature " />

IV

A. Appendix 1

223 <f e a t u r e C a t e g o r i e s name=" I n s t r u c t i o n s " featureType=" performance ">224 <f e a t u r e s name="IPC_1 . 0 " va lue=" 1 .0 " />225 </ f e a t u r e C a t e g o r i e s>226 <s t r u c t u r e s name=" inf ineon_aurix_tc297t_model " structureType=" System ">227 <s t r u c t u r e s name="ECU_Main" structureType="ECU">228 <s t r u c t u r e s name=" in f ineon_aur ix_tc297t " structureType=" M i c r o c o n t r o l l e r

">229 <modules x s i : t y p e=" am:Process ingUnit " name="CPU0" frequencyDomain="

QuartzCPU0? type=FrequencyDomain " d e f i n i t i o n="CPU0_type? type=P r o c e s s i n g U n i t D e f i n i t i o n " />

230 <modules x s i : t y p e=" am:Process ingUnit " name="CPU1" frequencyDomain="QuartzCPU1? type=FrequencyDomain " d e f i n i t i o n="CPU1_type? type=P r o c e s s i n g U n i t D e f i n i t i o n " />


232 </ s t r u c t u r e s>233 </ s t r u c t u r e s>234 </ s t r u c t u r e s>235 <x s l : f o r − e a c h s e l e c t=" //ea:HARDWARE−COMPONENT−PROTOTYPE">236 <x s l : v a r i a b l e name="name" s e l e c t="ea:SHORT−NAME" />237 <x s l : v a r i a b l e name="HW_Type">238 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">239 <xsl:with−param name=" s t r i n g " s e l e c t="ea:TYPE−TREF" />240 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />241 </ x s l : c a l l − t e m p l a t e>242 </ x s l : v a r i a b l e>243 <x s l : f o r − e a c h s e l e c t=" //ea:NODE">244 < x s l : i f t e s t="ea:SHORT−NAME = $HW_Type">245 <x s l : v a r i a b l e name="EX_Rate" s e l e c t="ea:EXECUTION−RATE" />246 < x s l : i f t e s t=" $EX_Rate != ' ' ">247 <x s l : v a r i a b l e name=" c lock_freq " s e l e c t="ea:EXECUTION−RATE" />248 <domains x s i : t y p e=" am:FrequencyDomain " name=" {$name} " c lockGat ing="

f a l s e ">249 <defau l tVa lue value=" {$ c lock_freq } " un i t="Hz" />250 </domains>251 </ x s l : i f>252 </ x s l : i f>253 </ x s l : f o r − e a c h>254 </ x s l : f o r − e a c h>255 </hwModel>256 <osModel>257 <operat ingSystems name="MICROSAR">258 <taskSchedu l e r s name="MICROSAR_task_scheduler_CPU0">259 <schedul ingAlgor i thm x s i : t y p e="am:OSEK" />260 </ taskSchedu l e r s>261 <taskSchedu l e r s name="MICROSAR_task_scheduler_CPU1">262 <schedul ingAlgor i thm x s i : t y p e="am:OSEK" />263 </ taskSchedu l e r s>264 <taskSchedu l e r s name="MICROSAR_task_scheduler_CPU2">265 <schedul ingAlgor i thm x s i : t y p e="am:OSEK" />266 </ taskSchedu l e r s>267 </ operat ingSystems>268 </osModel>269 <st imul iModel>270 <x s l : f o r − e a c h s e l e c t=" //ea:PERIODIC−CONSTRAINT">271 <s t i m u l i x s i : t y p e=" am:Per iod icSt imulus " name=" {ea:SHORT−NAME} ">272 <o f f s e t va lue=" 0 " un i t="ms" />273 <r e c u r r e n c e value=" {ea:NAME} " un i t="ms" />274 </ s t i m u l i>275 </ x s l : f o r − e a c h>276 </ st imul iModel>277 <eventModel>278 <x s l : f o r − e a c h s e l e c t=" //ea:EVENT−FUNCTION">279 <x s l : v a r i a b l e name=" eventName " s e l e c t="ea:SHORT−NAME" />280 <x s l : v a r i a b l e name=" eventType " s e l e c t="ea:NAME" />281 <x s l : v a r i a b l e name=" entity_name ">282 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">283 <xsl:with−param name=" s t r i n g " s e l e c t="ea:FUNCTION−IREF/

ea:FUNCTION−PROTOTYPE−TARGET−REF" />

V

A. Appendix 1

284 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />285 </ x s l : c a l l − t e m p l a t e>286 </ x s l : v a r i a b l e>287 <x s l : v a r i a b l e name=" e n t i t y ">288 <x s l : v a l u e − o f s e l e c t=" concat ($ entity_name , '? type=Task ' ) " />289 </ x s l : v a r i a b l e>290 <events x s i : t y p e=" am:ProcessEvent " name=" {$eventName} " eventType=" {$

eventType} " e n t i t y=" {$ e n t i t y } " />291 </ x s l : f o r − e a c h>292 </ eventModel>293 <const ra int sMode l>294 <x s l : f o r − e a c h s e l e c t=" //ea:EVENT−CHAIN">295 <x s l : v a r i a b l e name=" eventChainName " s e l e c t="ea:SHORT−NAME" />296 <x s l : v a r i a b l e name=" segment_refs " s e l e c t="ea:SEGMENT−REFS" />297 < x s l : i f t e s t=" $ segment_refs != ' ' ">298 <x s l : v a r i a b l e name=" st imulus ">299 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">300 <xsl:with−param name=" s t r i n g " s e l e c t="ea:STIMULUS−REF" />301 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />302 </ x s l : c a l l − t e m p l a t e>303 </ x s l : v a r i a b l e>304 <x s l : v a r i a b l e name=" concat_st imulus ">305 <x s l : v a l u e − o f s e l e c t=" concat ($ st imulus , '? type=ProcessEvent ' ) " />306 </ x s l : v a r i a b l e>307 <x s l : v a r i a b l e name=" response ">308 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">309 <xsl:with−param name=" s t r i n g " s e l e c t="ea:RESPONSE−REF" />310 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />311 </ x s l : c a l l − t e m p l a t e>312 </ x s l : v a r i a b l e>313 <x s l : v a r i a b l e name=" concat_response ">314 <x s l : v a l u e − o f s e l e c t=" concat ($ response , '? type=ProcessEvent ' ) " />315 </ x s l : v a r i a b l e>316 <eventChains name=" {$eventChainName} " s t imulus=" {$ concat_st imulus } "

re sponse=" {$ concat_response } ">317 <x s l : f o r − e a c h s e l e c t="ea:SEGMENT−REFS/ea:SEGMENT−REF">318 <x s l : v a r i a b l e name=" segments_name ">319 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">320 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />321 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />322 </ x s l : c a l l − t e m p l a t e>323 </ x s l : v a r i a b l e>324 <x s l : f o r − e a c h s e l e c t=" //ea:EVENT−CHAIN">325 < x s l : i f t e s t=" $segments_name = ea:SHORT−NAME">326 <x s l : v a r i a b l e name=" st imulus1 ">327 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">328 <xsl:with−param name=" s t r i n g " s e l e c t="ea:STIMULUS−REF" />329 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />330 </ x s l : c a l l − t e m p l a t e>331 </ x s l : v a r i a b l e>332 <x s l : v a r i a b l e name=" concat_st imulus1 ">333 <x s l : v a l u e − o f s e l e c t=" concat ($ st imulus1 , '? type=ProcessEvent

' ) " />334 </ x s l : v a r i a b l e>335 <x s l : v a r i a b l e name=" response1 ">336 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">337 <xsl:with−param name=" s t r i n g " s e l e c t="ea:RESPONSE−REF" />338 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />339 </ x s l : c a l l − t e m p l a t e>340 </ x s l : v a r i a b l e>341 <x s l : v a r i a b l e name=" concat_response1 ">342 <x s l : v a l u e − o f s e l e c t=" concat ($ response1 , '? type=ProcessEvent

' ) " />343 </ x s l : v a r i a b l e>344 <segments x s i : t y p e=" am:EventChainContainer ">345 <eventChain name=" {$segments_name} " s t imulus=" {$

concat_st imulus1 } " re sponse=" {$ concat_response1 } " />346 </ segments>347 </ x s l : i f>348 </ x s l : f o r − e a c h>

VI

A. Appendix 1

349 </ x s l : f o r − e a c h>350 </ eventChains>351 </ x s l : i f>352 </ x s l : f o r − e a c h>353 <x s l : f o r − e a c h s e l e c t=" //ea:AGE−CONSTRAINT">354 <x s l : v a r i a b l e name=" ageConstraint_name " s e l e c t="ea:SHORT−NAME" />355 <x s l : v a r i a b l e name=" ageValue " s e l e c t="ea:NAME" />356 <x s l : v a r i a b l e name=" scope ">357 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">358 <xsl:with−param name=" s t r i n g " s e l e c t="ea:SCOPE−REF" />359 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />360 </ x s l : c a l l − t e m p l a t e>361 </ x s l : v a r i a b l e>362 <x s l : v a r i a b l e name=" concat_scope ">363 <x s l : v a l u e − o f s e l e c t=" concat ($ scope , '? type=EventChain ' ) " />364 </ x s l : v a r i a b l e>365 <timingConst ra int s x s i : t y p e=" am:EventChainLatencyConstraint " name=" {$

ageConstraint_name } " scope=" {$ concat_scope } " type=" Reaction ">366 <minimum value=" {$ ageValue } " un i t="ms" />367 <maximum value=" {$ ageValue } " un i t="ms" />368 </ t imingConst ra in t s>369 </ x s l : f o r − e a c h>370 <x s l : f o r − e a c h s e l e c t=" //ea:PERIODIC−CONSTRAINT">371 <x s l : v a r i a b l e name=" per iod " s e l e c t="ea:NAME" />372 <x s l : v a r i a b l e name=" event_name ">373 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">374 <xsl:with−param name=" s t r i n g " s e l e c t="ea:EVENT−REF" />375 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />376 </ x s l : c a l l − t e m p l a t e>377 </ x s l : v a r i a b l e>378 <x s l : f o r − e a c h s e l e c t=" //ea:EVENT−FUNCTION">379 < x s l : i f t e s t=" $event_name = ea:SHORT−NAME">380 <x s l : v a r i a b l e name=" task_name ">381 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">382 <xsl:with−param name=" s t r i n g " s e l e c t="ea:FUNCTION−IREF/

ea:FUNCTION−PROTOTYPE−TARGET−REF" />383 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />384 </ x s l : c a l l − t e m p l a t e>385 </ x s l : v a r i a b l e>386 <x s l : v a r i a b l e name=" process_concat ">387 <x s l : v a l u e − o f s e l e c t=" concat ($ task_name , '? type=Task ' ) " />388 </ x s l : v a r i a b l e>389 <requirements x s i : t y p e=" am:ProcessRequirement " name=" {$task_name} "

s e v e r i t y=" C r i t i c a l " p r o c e s s=" {$ process_concat } ">390 <l i m i t x s i : t y p e=" am:TimeRequirementLimit " l imitType=" UpperLimit "

metr ic=" ResponseTime ">391 <l imi tVa lue value=" {$ per iod } " un i t="ms" />392 </ l i m i t>393 </ requi rements>394 </ x s l : i f>395 </ x s l : f o r − e a c h>396 </ x s l : f o r − e a c h>397 </ const ra int sMode l>398 <mappingModel>399 <s c h e d u l e r A l l o c a t i o n s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=

TaskScheduler " r e s p o n s i b i l i t y="CPU0? type=Process ingUni t " executingPU="CPU0? type=Process ingUni t " />

400 <s c h e d u l e r A l l o c a t i o n s c h e d u l e r="MICROSAR_task_scheduler_CPU1? type=TaskScheduler " r e s p o n s i b i l i t y="CPU1? type=Process ingUni t " executingPU="CPU1? type=Process ingUni t " />


402 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " e n t i t y="ABS_T? type=Runnable " />

403 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU1? type=TaskScheduler " e n t i t y=" Globa lBrakeContro l l e r ? type=Runnable " />

404 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU1? type=TaskScheduler " e n t i t y="BrakePedalLDM_T? type=Runnable " />

405 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU2? type=

VII

A. Appendix 1

TaskScheduler " e n t i t y=" BrakeTorqMap? type=Runnable " />406 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=

TaskScheduler " e n t i t y=" BrakeActuatorLDM? type=Runnable " />407 <t a s k A l l o c a t i o n task="ABS_FL_Pt? type=Task " s c h e d u l e r="

MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

408 <t a s k A l l o c a t i o n task="ABS_FR_Pt? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

409 <t a s k A l l o c a t i o n task="ABS_RL_Pt? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

410 <t a s k A l l o c a t i o n task="ABS_RR_Pt? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

411 <t a s k A l l o c a t i o n task=" pGloba lBrakeContro l l e r ? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU1? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

412 <t a s k A l l o c a t i o n task="pLDM_Brake_FL? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

413 <t a s k A l l o c a t i o n task="pLDM_Brake_FR? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

414 <t a s k A l l o c a t i o n task="pLDM_Brake_RL? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

415 <t a s k A l l o c a t i o n task="pLDM_Brake_RR? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

416 <t a s k A l l o c a t i o n task=" pBrakeTorqueMap? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU2? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

417 <t a s k A l l o c a t i o n task=" pBrakePedalLDM? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU2? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

418 </mappingModel>419 </am:Amalthea>420 </ x s l : t e m p l a t e>421 </ x s l : s t y l e s h e e t>

Listing A.2: XSLT code for transforming AUTOSAR to AMALTHEA model12 <?xml v e r s i o n=" 1 .0 " encoding="UTF−8" ?>3 <!−− x s l s t y l e s h e e t d e c l a r a t i o n −−>4 <x s l : s t y l e s h e e t x m l n s : x s l=" h t t p : //www. w3 . org /1999/XSL/Transform " xmlns :ar=" h t t p : //

autosar . org /schema/ r4 . 0 " x m l n s : e x s l t=" h t t p : // e x s l t . org /common" v e r s i o n=" 1 .0 "extens ion−e lement−pre f ixes=" e x s l t ">

5 <x s l : o u t p u t method=" xml " indent=" yes " />6 <!−− This template i s used to e x t r a c t a sub−str ing with in a s t r i n g a f t e r the l a s t

occurence o f the d e l i m i t e r ' / ' −−>7 <x s l : t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">8 <xsl :param name=" s t r i n g " />9 <xsl :param name=" d e l i m i t e r " />

10 <x s l : c h o o s e>11 <xsl :when t e s t=" conta in s ($ s t r i n g , $ d e l i m i t e r ) ">12 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">13 <xsl:with−param name=" s t r i n g " s e l e c t=" s u b s t r i n g − a f t e r ($ s t r i n g , $ d e l i m i t e r

) " />14 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" $ d e l i m i t e r " />15 </ x s l : c a l l − t e m p l a t e>16 </ xs l :when>17 <x s l : o t h e r w i s e>18 <x s l : v a l u e − o f s e l e c t=" $ s t r i n g " />19 </ x s l : o t h e r w i s e>20 </ x s l : c h o o s e>21 </ x s l : t e m p l a t e>22 <!−− This template i s used to get the s t i m u l i name −−>23 <x s l : t e m p l a t e name=" get−stimuli−name ">

VIII

A. Appendix 1

24 <xsl :param name=" taskName " />25 <x s l : f o r − e a c h s e l e c t=" //ar:TD−EVENT−SWC−INTERNAL−BEHAVIOR/ar:COMPONENT−IREF/

ar:TARGET−COMPONENT−REF">26 <x s l : v a r i a b l e name=" EventFunctionName " s e l e c t=" . . / . . / ar:SHORT−NAME" />27 <x s l : v a r i a b l e name=" Var2 ">28 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">29 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />30 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />31 </ x s l : c a l l − t e m p l a t e>32 </ x s l : v a r i a b l e>33 <!−− <varoutput>34 <x s l : v a l u e − o f s e l e c t=" $Var2 " />35 </ varoutput> −−>36 < x s l : i f t e s t=" $taskName = $Var2 ">37 <x s l : f o r − e a c h s e l e c t=" //ar:PERIODIC−EVENT−TRIGGERING/ar:EVENT−REF">38 <x s l : v a r i a b l e name=" Var3 ">39 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">40 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />41 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />42 </ x s l : c a l l − t e m p l a t e>43 </ x s l : v a r i a b l e>44 < x s l : i f t e s t=" $Var3 = $EventFunctionName ">45 <x s l : v a l u e − o f s e l e c t=" concat ( . . / ar:SHORT−NAME, '? type=Per iod icSt imulus

' ) " />46 </ x s l : i f>47 </ x s l : f o r − e a c h>48 </ x s l : i f>49 </ x s l : f o r − e a c h>50 </ x s l : t e m p l a t e>51 <!−− This template i s used to get the i n s t r u c t i o n count f o r each runnable −−>52 <x s l : t e m p l a t e name=" get− instruct ion−count ">53 <xsl :param name=" runnableName " />54 <x s l : f o r − e a c h s e l e c t=" //ar:EXECUTION−TIME−CONSTRAINT">55 <x s l : v a r i a b l e name=" runnable_ent i ty ">56 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">57 <xsl:with−param name=" s t r i n g " s e l e c t="ar:EXECUTABLE−REF" />58 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />59 </ x s l : c a l l − t e m p l a t e>60 </ x s l : v a r i a b l e>61 < x s l : i f t e s t=" $runnableName = $ runnable_ent i ty ">62 <x s l : v a r i a b l e name=" ins t ruct ion_count " s e l e c t="ar:MAXIMUM/ar:CSE−CODE" />63 <x s l : v a l u e − o f s e l e c t=" $ ins t ruct ion_count " />64 </ x s l : i f>65 </ x s l : f o r − e a c h>66 </ x s l : t e m p l a t e>67 <!−− This template i s used to get the proce s sProto types −−>68 <x s l : t e m p l a t e name=" get_processPrototypes ">69 <proces sPrototypes name=" ">70 <x s l : f o r − e a c h s e l e c t=" //ar:EXECUTION−ORDER−CONSTRAINT/ar:ORDERED−ELEMENTS/

ar:EOC−EXECUTABLE−ENTITY−REF">71 <x s l : v a r i a b l e name=" d i r e c t _ s u c c e s s o r " s e l e c t="ar:DIRECT−SUCCESSOR−REFS" />72 < x s l : i f t e s t=" $ d i r e c t _ s u c c e s s o r != ' ' ">73 <x s l : v a r i a b l e name=" o r i g i n ">74 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">75 <xsl:with−param name=" s t r i n g " s e l e c t="ar:EXECUTABLE−REF" />76 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />77 </ x s l : c a l l − t e m p l a t e>78 </ x s l : v a r i a b l e>79 <x s l : v a r i a b l e name=" concat_or ig in ">80 <x s l : v a l u e − o f s e l e c t=" concat ($ o r i g i n , '? type=Runnable ' ) " />81 </ x s l : v a r i a b l e>82 <x s l : v a r i a b l e name=" eo_successor_name ">83 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">84 <xsl:with−param name=" s t r i n g " s e l e c t="ar:DIRECT−SUCCESSOR−REFS/

ar:DIRECT−SUCCESSOR−REF" />85 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />86 </ x s l : c a l l − t e m p l a t e>87 </ x s l : v a r i a b l e>88 <x s l : f o r − e a c h s e l e c t=" //ar:EOC−EXECUTABLE−ENTITY−REF">89 < x s l : i f t e s t=" $eo_successor_name = ar:SHORT−NAME">

IX

A. Appendix 1

90 <x s l : v a r i a b l e name=" t a r g e t ">91 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">92 <xsl:with−param name=" s t r i n g " s e l e c t="ar:EXECUTABLE−REF" />93 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />94 </ x s l : c a l l − t e m p l a t e>95 </ x s l : v a r i a b l e>96 <x s l : v a r i a b l e name=" concat_target ">97 <x s l : v a l u e − o f s e l e c t=" concat ($ target , '? type=Runnable ' ) " />98 </ x s l : v a r i a b l e>99 <orderPrecedenceSpec o r i g i n=" {$ concat_or ig in } " t a r g e t=" {$

concat_target } " orderType=" d i r ec tOrder " />100 </ x s l : i f>101 </ x s l : f o r − e a c h>102 </ x s l : i f>103 </ x s l : f o r − e a c h>104 </ proce s sPrototypes>105 </ x s l : t e m p l a t e>106 <!−− x s l template d e c l a r a t i o n :107 template t e l l s the x l s t p r o c e s s o r about which s e c t i o n o f xml108 document to be formatted . I t takes an XPath e x p r e s s i o n .109 In our case , i t i s matching root element −−>110 <x s l : t e m p l a t e match=" / ">111 <!−− New Line −−>112 <x s l : t e x t />113 <am:Amalthea xmlns:am=" h t t p : //app4mc . e c l i p s e . org / amalthea / 0 . 9 . 2 " xmlns:xmi="

h t t p : //www. omg . org /XMI" x m l n s : x s i=" h t t p : //www. w3 . org /2001/XMLSchema−instance "x m i : v e r s i o n=" 2 .0 ">

114 <swModel>115 <x s l : f o r − e a c h s e l e c t=" //ar:SW−COMPONENT−PROTOTYPE">116 <x s l : v a r i a b l e name=" taskName " s e l e c t="ar:SHORT−NAME" />117 <x s l : v a r i a b l e name=" Var1 ">118 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">119 <xsl:with−param name=" s t r i n g " s e l e c t="ar:TYPE−TREF" />120 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />121 </ x s l : c a l l − t e m p l a t e>122 </ x s l : v a r i a b l e>123 <x s l : v a r i a b l e name=" r e f 1 ">124 <x s l : v a l u e − o f s e l e c t=" concat ($ Var1 , '? type=Runnable ' ) " />125 </ x s l : v a r i a b l e>126 <x s l : v a r i a b l e name=" call_seq_name ">127 <x s l : v a l u e − o f s e l e c t=" concat ( 'CS_' , $ taskName ) " />128 </ x s l : v a r i a b l e>129 <x s l : v a r i a b l e name=" stimuli_name ">130 <x s l : c a l l − t e m p l a t e name=" get−stimuli−name ">131 <xsl:with−param name=" taskName " s e l e c t=" $taskName " />132 </ x s l : c a l l − t e m p l a t e>133 </ x s l : v a r i a b l e>134 <ta s ks name=" {$taskName} " s t i m u l i=" {$ stimuli_name } " preemption="

preemptive " mult ip l eTaskAct ivat ionLimit=" 1 ">135 <cal lGraph>136 <graphEntr i e s x s i : t y p e=" am:CallSequence " name=" {$ call_seq_name} ">137 <c a l l s x s i : t y p e=" am:TaskRunnableCall " runnable=" {$ r e f 1 } " />138 </ graphEntr i e s>139 </ cal lGraph>140 </ t as k s>141 </ x s l : f o r − e a c h>142 <x s l : f o r − e a c h s e l e c t=" //ar:RUNNABLE−ENTITY">143 <x s l : v a r i a b l e name=" runnableName " s e l e c t="ar:SHORT−NAME" />144 <x s l : v a r i a b l e name=" r e f 3 ">145 <x s l : c a l l − t e m p l a t e name=" get− instruct ion−count ">146 <xsl:with−param name=" runnableName " s e l e c t=" $runnableName " />147 </ x s l : c a l l − t e m p l a t e>148 </ x s l : v a r i a b l e>149 <runnables name=" {$runnableName} " c a l l b a c k=" f a l s e " s e r v i c e=" f a l s e ">150 <runnableItems x s i : t y p e=" am:ExecutionNeed ">151 <d e f a u l t key=" I n s t r u c t i o n s ">152 <value x s i : t y p e=" am:NeedConstant " va lue=" {$ r e f 3 } " />153 </ d e f a u l t>154 </ runnableItems>155 </ runnables>

X

A. Appendix 1

156 </ x s l : f o r − e a c h>157 <x s l : c a l l − t e m p l a t e name=" get_processPrototypes " />158 </swModel>159 <hwModel>160 <d e f i n i t i o n s x s i : t y p e=" am:Proce s s ingUn i tDe f in i t i on " name="CPU0_type" puType



="CPU" f e a t u r e s=" I n s t r u c t i o n s /IPC_1 . 0 ? type=HwFeature " />163 <f e a t u r e C a t e g o r i e s name=" I n s t r u c t i o n s " featureType=" performance ">164 <f e a t u r e s name="IPC_1 . 0 " va lue=" 1 .0 " />165 </ f e a t u r e C a t e g o r i e s>166 <s t r u c t u r e s name=" inf ineon_aurix_tc297t_model " structureType=" System ">167 <s t r u c t u r e s name="ECU_Main" structureType="ECU">168 <s t r u c t u r e s name=" in f ineon_aur ix_tc297t " structureType=" M i c r o c o n t r o l l e r

">169 <modules x s i : t y p e=" am:Process ingUnit " name="CPU0" frequencyDomain="

QuartzCPU0? type=FrequencyDomain " d e f i n i t i o n="CPU0_type? type=P r o c e s s i n g U n i t D e f i n i t i o n " />



172 </ s t r u c t u r e s>173 </ s t r u c t u r e s>174 </ s t r u c t u r e s>175 <x s l : f o r − e a c h s e l e c t=" //ar:HW−ELEMENT">176 <x s l : v a r i a b l e name="name" s e l e c t="ar:SHORT−NAME" />177 < x s l : i f t e s t="ar:CATEGORY = 'CPU' ">178 <x s l : v a r i a b l e name="HW_Type">179 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">180 <xsl:with−param name=" s t r i n g " s e l e c t="ar:HW−TYPE−REF" />181 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />182 </ x s l : c a l l − t e m p l a t e>183 </ x s l : v a r i a b l e>184 <x s l : f o r − e a c h s e l e c t=" //ar:HW−TYPE">185 < x s l : i f t e s t="ar:SHORT−NAME = $HW_Type">186 <x s l : v a r i a b l e name=" c lock_freq " s e l e c t="ar:HW−ATTRIBUTE−VALUES/

ar:HW−ATTRIBUTE−VALUE/ ar:V " />187 <domains x s i : t y p e=" am:FrequencyDomain " name=" {$name} " c lockGat ing="

f a l s e ">188 <defau l tVa lue value=" {$ c lock_freq } " un i t="Hz" />189 </domains>190 </ x s l : i f>191 </ x s l : f o r − e a c h>192 </ x s l : i f>193 </ x s l : f o r − e a c h>194 </hwModel>195 <osModel>196 <x s l : f o r − e a c h s e l e c t=" //ar:SYSTEM">197 <x s l : v a r i a b l e name="oSName" s e l e c t="ar:SHORT−NAME" />198 <x s l : v a r i a b l e name=" categoryName " s e l e c t="ar:CATEGORY" />199 < x s l : i f t e s t=" $categoryName = ' Operating System ' ">200 <operat ingSystems name=" {$oSName} ">201 <taskSchedu l e r s name="MICROSAR_task_scheduler_CPU0">202 <schedul ingAlgor i thm x s i : t y p e="am:OSEK" />203 </ taskSchedu l e r s>204 <taskSchedu l e r s name="MICROSAR_task_scheduler_CPU1">205 <schedul ingAlgor i thm x s i : t y p e="am:OSEK" />206 </ taskSchedu l e r s>207 <taskSchedu l e r s name="MICROSAR_task_scheduler_CPU2">208 <schedul ingAlgor i thm x s i : t y p e="am:OSEK" />209 </ taskSchedu l e r s>210 </ operat ingSystems>211 </ x s l : i f>212 </ x s l : f o r − e a c h>213 </osModel>

XI

A. Appendix 1

214 <st imul iModel>215 <x s l : f o r − e a c h s e l e c t=" //ar:PERIODIC−EVENT−TRIGGERING">216 <s t i m u l i x s i : t y p e=" am:Per iod icSt imulus " name=" {ar:SHORT−NAME} ">217 <o f f s e t va lue=" 0 " un i t="ms" />218 <r e c u r r e n c e value=" {ar:PERIOD/ar:CSE−CODE} " un i t="ms" />219 </ s t i m u l i>220 </ x s l : f o r − e a c h>221 </ st imul iModel>222 <eventModel>223 <x s l : f o r − e a c h s e l e c t=" //ar:TD−EVENT−SWC−INTERNAL−BEHAVIOR">224 <x s l : v a r i a b l e name=" eventName " s e l e c t="ar:SHORT−NAME" />225 <x s l : v a r i a b l e name=" eventType " s e l e c t="

ar:TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE" />226 <x s l : v a r i a b l e name=" entity_name ">227 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">228 <xsl:with−param name=" s t r i n g " s e l e c t="ar:COMPONENT−IREF/

ar:TARGET−COMPONENT−REF" />229 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />230 </ x s l : c a l l − t e m p l a t e>231 </ x s l : v a r i a b l e>232 <x s l : v a r i a b l e name=" e n t i t y ">233 <x s l : v a l u e − o f s e l e c t=" concat ($ entity_name , '? type=Task ' ) " />234 </ x s l : v a r i a b l e>235 <x s l : c h o o s e>236 <xsl :when t e s t=" $eventType = 'RUNNABLE−ENTITY−ACTIVATED' ">237 <events x s i : t y p e=" am:ProcessEvent " name=" {$eventName} " eventType="

a c t i v a t e " e n t i t y=" {$ e n t i t y } " />238 </ xs l :when>239 <x s l : o t h e r w i s e>240 <events x s i : t y p e=" am:ProcessEvent " name=" {$eventName} " eventType="

terminate " e n t i t y=" {$ e n t i t y } " />241 </ x s l : o t h e r w i s e>242 </ x s l : c h o o s e>243 </ x s l : f o r − e a c h>244 </ eventModel>245 <const ra int sMode l>246 <x s l : f o r − e a c h s e l e c t=" //ar:TIMING−DESCRIPTION−EVENT−CHAIN">247 <x s l : v a r i a b l e name=" eventChainName " s e l e c t="ar:SHORT−NAME" />248 <x s l : v a r i a b l e name=" segment_refs " s e l e c t="ar:SEGMENT−REFS" />249 < x s l : i f t e s t=" $ segment_refs != ' ' ">250 <x s l : v a r i a b l e name=" st imulus ">251 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">252 <xsl:with−param name=" s t r i n g " s e l e c t="ar:STIMULUS−REF" />253 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />254 </ x s l : c a l l − t e m p l a t e>255 </ x s l : v a r i a b l e>256 <x s l : v a r i a b l e name=" concat_st imulus ">257 <x s l : v a l u e − o f s e l e c t=" concat ($ st imulus , '? type=ProcessEvent ' ) " />258 </ x s l : v a r i a b l e>259 <x s l : v a r i a b l e name=" response ">260 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">261 <xsl:with−param name=" s t r i n g " s e l e c t="ar:RESPONSE−REF" />262 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />263 </ x s l : c a l l − t e m p l a t e>264 </ x s l : v a r i a b l e>265 <x s l : v a r i a b l e name=" concat_response ">266 <x s l : v a l u e − o f s e l e c t=" concat ($ response , '? type=ProcessEvent ' ) " />267 </ x s l : v a r i a b l e>268 <eventChains name=" {$eventChainName} " s t imulus=" {$ concat_st imulus } "

re sponse=" {$ concat_response } ">269 <x s l : f o r − e a c h s e l e c t="ar:SEGMENT−REFS/ar:SEGMENT−REF">270 <x s l : v a r i a b l e name=" segments_name ">271 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">272 <xsl:with−param name=" s t r i n g " s e l e c t=" cur rent ( ) " />273 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />274 </ x s l : c a l l − t e m p l a t e>275 </ x s l : v a r i a b l e>276 <x s l : f o r − e a c h s e l e c t=" //ar:TIMING−DESCRIPTION−EVENT−CHAIN">277 < x s l : i f t e s t=" $segments_name = ar:SHORT−NAME">278 <x s l : v a r i a b l e name=" st imulus1 ">

XII

A. Appendix 1

279 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">280 <xsl:with−param name=" s t r i n g " s e l e c t="ar:STIMULUS−REF" />281 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />282 </ x s l : c a l l − t e m p l a t e>283 </ x s l : v a r i a b l e>284 <x s l : v a r i a b l e name=" concat_st imulus1 ">285 <x s l : v a l u e − o f s e l e c t=" concat ($ st imulus1 , '? type=ProcessEvent

' ) " />286 </ x s l : v a r i a b l e>287 <x s l : v a r i a b l e name=" response1 ">288 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">289 <xsl:with−param name=" s t r i n g " s e l e c t="ar:RESPONSE−REF" />290 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />291 </ x s l : c a l l − t e m p l a t e>292 </ x s l : v a r i a b l e>293 <x s l : v a r i a b l e name=" concat_response1 ">294 <x s l : v a l u e − o f s e l e c t=" concat ($ response1 , '? type=ProcessEvent

' ) " />295 </ x s l : v a r i a b l e>296 <segments x s i : t y p e=" am:EventChainContainer ">297 <eventChain name=" {$segments_name} " s t imulus=" {$

concat_st imulus1 } " re sponse=" {$ concat_response1 } " />298 </ segments>299 </ x s l : i f>300 </ x s l : f o r − e a c h>301 </ x s l : f o r − e a c h>302 </ eventChains>303 </ x s l : i f>304 </ x s l : f o r − e a c h>305 <x s l : f o r − e a c h s e l e c t=" //ar:LATENCY−TIMING−CONSTRAINT">306 <x s l : v a r i a b l e name=" latencyConstraint_name " s e l e c t="ar:SHORT−NAME" />307 <x s l : v a r i a b l e name=" latencyValue " s e l e c t="ar:MAXIMUM/ar:CSE−CODE" />308 <x s l : v a r i a b l e name=" scope ">309 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">310 <xsl:with−param name=" s t r i n g " s e l e c t="ar:SCOPE−REF" />311 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />312 </ x s l : c a l l − t e m p l a t e>313 </ x s l : v a r i a b l e>314 <x s l : v a r i a b l e name=" concat_scope ">315 <x s l : v a l u e − o f s e l e c t=" concat ($ scope , '? type=EventChain ' ) " />316 </ x s l : v a r i a b l e>317 <timingConst ra int s x s i : t y p e=" am:EventChainLatencyConstraint " name=" {$

latencyConstraint_name } " scope=" {$ concat_scope } " type=" Reaction ">318 <minimum value=" {$ latencyValue } " un i t="ms" />319 <maximum value=" {$ latencyValue } " un i t="ms" />320 </ t imingConst ra in t s>321 </ x s l : f o r − e a c h>322 <x s l : f o r − e a c h s e l e c t=" //ar:PERIODIC−EVENT−TRIGGERING">323 <x s l : v a r i a b l e name=" per iod " s e l e c t=" ar:PERIOD/ar:CSE−CODE" />324 <x s l : v a r i a b l e name=" event_name ">325 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">326 <xsl:with−param name=" s t r i n g " s e l e c t="ar:EVENT−REF" />327 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />328 </ x s l : c a l l − t e m p l a t e>329 </ x s l : v a r i a b l e>330 <x s l : f o r − e a c h s e l e c t=" //ar:TD−EVENT−SWC−INTERNAL−BEHAVIOR">331 < x s l : i f t e s t=" $event_name = ar:SHORT−NAME">332 <x s l : v a r i a b l e name=" task_name ">333 <x s l : c a l l − t e m p l a t e name=" s u b s t r i n g − a f t e r − l a s t ">334 <xsl:with−param name=" s t r i n g " s e l e c t="ar:COMPONENT−IREF/

ar:TARGET−COMPONENT−REF" />335 <xsl:with−param name=" d e l i m i t e r " s e l e c t=" '/ ' " />336 </ x s l : c a l l − t e m p l a t e>337 </ x s l : v a r i a b l e>338 <x s l : v a r i a b l e name=" process_concat ">339 <x s l : v a l u e − o f s e l e c t=" concat ($ task_name , '? type=Task ' ) " />340 </ x s l : v a r i a b l e>341 <requirements x s i : t y p e=" am:ProcessRequirement " name=" {$task_name} "

s e v e r i t y=" C r i t i c a l " p r o c e s s=" {$ process_concat } ">342 <l i m i t x s i : t y p e=" am:TimeRequirementLimit " l imitType=" UpperLimit "

XIII

A. Appendix 1

metr ic=" ResponseTime ">343 <l imi tVa lue value=" {$ per iod } " un i t="ms" />344 </ l i m i t>345 </ requi rements>346 </ x s l : i f>347 </ x s l : f o r − e a c h>348 </ x s l : f o r − e a c h>349 </ const ra int sMode l>350 <mappingModel>351 <s c h e d u l e r A l l o c a t i o n s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=

TaskScheduler " r e s p o n s i b i l i t y="CPU0? type=Process ingUni t " executingPU="CPU0? type=Process ingUni t " />



354 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " e n t i t y="ABS_T? type=Runnable " />

355 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU1? type=TaskScheduler " e n t i t y=" Globa lBrakeContro l l e r ? type=Runnable " />

356 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU1? type=TaskScheduler " e n t i t y="BrakePedalLDM_T? type=Runnable " />

357 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU2? type=TaskScheduler " e n t i t y=" BrakeTorqMap? type=Runnable " />

358 <runnab l eA l l o ca t i on s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " e n t i t y=" BrakeActuatorLDM? type=Runnable " />

359 <t a s k A l l o c a t i o n task="ABS_FL_Pt? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

360 <t a s k A l l o c a t i o n task="ABS_FR_Pt? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

361 <t a s k A l l o c a t i o n task="ABS_RL_Pt? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

362 <t a s k A l l o c a t i o n task="ABS_RR_Pt? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

363 <t a s k A l l o c a t i o n task=" pGloba lBrakeContro l l e r ? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU1? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

364 <t a s k A l l o c a t i o n task="pLDM_Brake_FL? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

365 <t a s k A l l o c a t i o n task="pLDM_Brake_FR? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

366 <t a s k A l l o c a t i o n task="pLDM_Brake_RL? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

367 <t a s k A l l o c a t i o n task="pLDM_Brake_RR? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU0? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

368 <t a s k A l l o c a t i o n task=" pBrakeTorqueMap? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU2? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

369 <t a s k A l l o c a t i o n task=" pBrakePedalLDM? type=Task " s c h e d u l e r="MICROSAR_task_scheduler_CPU2? type=TaskScheduler " a f f i n i t y="CPU2? type=Process ingUnit CPU1? type=Process ingUni t CPU0? type=Process ingUni t " />

370 </mappingModel>371 </am:Amalthea>372 </ x s l : t e m p l a t e>373 </ x s l : s t y l e s h e e t>

Listing A.3: AUTOSAR model for BBW component12 <?xml v e r s i o n=" 1 .0 " encoding="UTF−8" ?>

XIV

A. Appendix 1

3 <AUTOSAR xmlns=" h t t p : // autosar . org /schema/ r4 . 0 " x m l n s : x s i=" h t t p : //www. w3 . org /2001/XMLSchema−instance " xs i : s chemaLocat ion=" h t t p : // autosar . org /schema/ r4 . 0AUTOSAR_4−2−2. xsd ">

4 <AR−PACKAGES>5 <AR−PACKAGE>6 <SHORT−NAME>BBW_SWC_Description</SHORT−NAME>7 <AR−PACKAGES>8 <AR−PACKAGE>9 <SHORT−NAME>Const ra int s</SHORT−NAME>

10 <ELEMENTS>11 <SWC−TIMING>12 <SHORT−NAME>TimingConstraints</SHORT−NAME>13 <TIMING−GUARANTEES>14 <EXECUTION−TIME−CONSTRAINT UUID=" ">15 <SHORT−NAME>EX_ABS_T</SHORT−NAME>16 <EXECUTABLE−REF DEST="RUNNABLE−ENTITY">/BBW_SWC_Description/

SwComponents/ABS_T_Information/ABS_T//ABS_T</EXECUTABLE−REF>17 <EXECUTION−TIME−TYPE>NET</EXECUTION−TIME−TYPE>18 <MAXIMUM>19 <CSE−CODE>150000</CSE−CODE>20 </MAXIMUM>21 </EXECUTION−TIME−CONSTRAINT>22 <EXECUTION−TIME−CONSTRAINT UUID=" ">23 <SHORT−NAME>EX_BrakePedalLDM_T</SHORT−NAME>24 <EXECUTABLE−REF DEST="RUNNABLE−ENTITY">/BBW_SWC_Description/

SwComponents/BrakePedalLDM_T_Information/BrakePedalLDM_T//BrakePedalLDM_T</EXECUTABLE−REF>

25 <EXECUTION−TIME−TYPE>NET</EXECUTION−TIME−TYPE>26 <MAXIMUM>27 <CSE−CODE>60000</CSE−CODE>28 </MAXIMUM>29 </EXECUTION−TIME−CONSTRAINT>30 <EXECUTION−TIME−CONSTRAINT UUID=" ">31 <SHORT−NAME>EX_BrakeTorqMap</SHORT−NAME>32 <EXECUTABLE−REF DEST="RUNNABLE−ENTITY">/BBW_SWC_Description/

SwComponents/BrakeTorqMap_Information/BrakeTorqMap//BrakeTorqMap</EXECUTABLE−REF>

33 <EXECUTION−TIME−TYPE>NET</EXECUTION−TIME−TYPE>34 <MAXIMUM>35 <CSE−CODE>90000</CSE−CODE>36 </MAXIMUM>37 </EXECUTION−TIME−CONSTRAINT>38 <EXECUTION−TIME−CONSTRAINT UUID=" ">39 <SHORT−NAME>EX_GlobalBrakeController</SHORT−NAME>40 <EXECUTABLE−REF DEST="RUNNABLE−ENTITY">/BBW_SWC_Description/

SwComponents/ GlobalBrakeContro l l e r_Informat ion / Globa lBrakeContro l l e r //Globa lBrakeContro l l e r</EXECUTABLE−REF>

41 <EXECUTION−TIME−TYPE>NET</EXECUTION−TIME−TYPE>42 <MAXIMUM>43 <CSE−CODE>120000</CSE−CODE>44 </MAXIMUM>45 </EXECUTION−TIME−CONSTRAINT>46 <LATENCY−TIMING−CONSTRAINT UUID=" ">47 <SHORT−NAME>LatencyConstraint_FL</SHORT−NAME>48 <CATEGORY />49 <LATENCY−CONSTRAINT−TYPE>REACTION</LATENCY−CONSTRAINT−TYPE>50 <SCOPE−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/

BBW_SWC_Description/ EventChains //EC_Sequence_FL</SCOPE−REF>51 <MAXIMUM>52 <CSE−CODE>20</CSE−CODE>53 </MAXIMUM>54 </LATENCY−TIMING−CONSTRAINT>55 <LATENCY−TIMING−CONSTRAINT UUID=" ">56 <SHORT−NAME>LatencyConstraint_FR</SHORT−NAME>57 <LATENCY−CONSTRAINT−TYPE>REACTION</LATENCY−CONSTRAINT−TYPE>58 <SCOPE−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/

BBW_SWC_Description/ EventChains //EC_Sequence_FR</SCOPE−REF>59 <MAXIMUM>60 <CSE−CODE>20</CSE−CODE>61 </MAXIMUM>

XV

A. Appendix 1

62 </LATENCY−TIMING−CONSTRAINT>63 <LATENCY−TIMING−CONSTRAINT UUID=" ">64 <SHORT−NAME>LatencyConstraint_RL</SHORT−NAME>65 <LATENCY−CONSTRAINT−TYPE>REACTION</LATENCY−CONSTRAINT−TYPE>66 <SCOPE−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/

BBW_SWC_Description/ EventChains //EC_Sequence_RL</SCOPE−REF>67 <MAXIMUM>68 <CSE−CODE>20</CSE−CODE>69 </MAXIMUM>70 </LATENCY−TIMING−CONSTRAINT>71 <PERIODIC−EVENT−TRIGGERING UUID=" ">72 <SHORT−NAME>Periodic_Constraint_1</SHORT−NAME>73 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_BrakePedalLDM</EVENT−REF>74 <PERIOD>75 <CSE−CODE>2</CSE−CODE>76 </PERIOD>77 </PERIODIC−EVENT−TRIGGERING>78 <PERIODIC−EVENT−TRIGGERING S=" " UUID=" ">79 <SHORT−NAME>Periodic_Constraint_10</SHORT−NAME>80 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_ABS_RL_Pt</EVENT−REF>81 <PERIOD>82 <CSE−CODE>5</CSE−CODE>83 </PERIOD>84 </PERIODIC−EVENT−TRIGGERING>85 <PERIODIC−EVENT−TRIGGERING UUID=" ">86 <SHORT−NAME>Periodic_Constraint_2</SHORT−NAME>87 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /EventBrakeTorqueMap</EVENT−REF>88 <PERIOD>89 <CSE−CODE>3</CSE−CODE>90 </PERIOD>91 </PERIODIC−EVENT−TRIGGERING>92 <PERIODIC−EVENT−TRIGGERING UUID=" ">93 <SHORT−NAME>Periodic_Constraint_3</SHORT−NAME>94 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events / Event_GlobalBrakeControl ler</EVENT−REF>95 <PERIOD>96 <CSE−CODE>4</CSE−CODE>97 </PERIOD>98 </PERIODIC−EVENT−TRIGGERING>99 <PERIODIC−EVENT−TRIGGERING UUID=" ">

100 <SHORT−NAME>Periodic_Constraint_4</SHORT−NAME>101 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_FL</EVENT−REF>102 <PERIOD S=" ">103 <CSE−CODE>6</CSE−CODE>104 </PERIOD>105 </PERIODIC−EVENT−TRIGGERING>106 <PERIODIC−EVENT−TRIGGERING UUID=" ">107 <SHORT−NAME>Periodic_Constraint_5</SHORT−NAME>108 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_FR</EVENT−REF>109 <PERIOD>110 <CSE−CODE>6</CSE−CODE>111 </PERIOD>112 </PERIODIC−EVENT−TRIGGERING>113 <PERIODIC−EVENT−TRIGGERING UUID=" ">114 <SHORT−NAME>Periodic_Constraint_6</SHORT−NAME>115 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_RL</EVENT−REF>116 <PERIOD>117 <CSE−CODE>6</CSE−CODE>118 </PERIOD>119 </PERIODIC−EVENT−TRIGGERING>120 <PERIODIC−EVENT−TRIGGERING UUID=" ">121 <SHORT−NAME>Periodic_Constraint_7</SHORT−NAME>122 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_RR</EVENT−REF>

XVI

A. Appendix 1

123 <PERIOD>124 <CSE−CODE>6</CSE−CODE>125 </PERIOD>126 </PERIODIC−EVENT−TRIGGERING>127 <PERIODIC−EVENT−TRIGGERING UUID=" ">128 <SHORT−NAME>Periodic_Constraint_8</SHORT−NAME>129 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_ABS_FL_Pt</EVENT−REF>130 <PERIOD>131 <CSE−CODE>5</CSE−CODE>132 </PERIOD>133 </PERIODIC−EVENT−TRIGGERING>134 <PERIODIC−EVENT−TRIGGERING UUID=" ">135 <SHORT−NAME>Periodic_Constraint_9</SHORT−NAME>136 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_ABS_FR_Pt</EVENT−REF>137 <PERIOD>138 <CSE−CODE>5</CSE−CODE>139 </PERIOD>140 </PERIODIC−EVENT−TRIGGERING>141 </TIMING−GUARANTEES>142 <TIMING−REQUIREMENTS>143 <EXECUTION−TIME−CONSTRAINT UUID=" ">144 <SHORT−NAME>EX_BrakeActuatorLDM</SHORT−NAME>145 <EXECUTABLE−REF DEST="RUNNABLE−ENTITY">/BBW_SWC_Description/

SwComponents/BrakeActuatorLDM_Information/BrakeActuatorLDM//BrakeActuatorLDM</EXECUTABLE−REF>

146 <EXECUTION−TIME−TYPE>NET</EXECUTION−TIME−TYPE>147 <MAXIMUM>148 <CSE−CODE>180000</CSE−CODE>149 </MAXIMUM>150 </EXECUTION−TIME−CONSTRAINT>151 <EXECUTION−ORDER−CONSTRAINT>152 <SHORT−NAME>Execution Order</SHORT−NAME>153 <EXECUTION−ORDER−CONSTRAINT−TYPE>ORDINARY−EOC</

EXECUTION−ORDER−CONSTRAINT−TYPE>154 <ORDERED−ELEMENTS>155 <EOC−EXECUTABLE−ENTITY−REF>156 <SHORT−NAME>EO_ABS_T</SHORT−NAME>157 <DIRECT−SUCCESSOR−REFS>158 <DIRECT−SUCCESSOR−REF DEST="EOC−EXECUTABLE−ENTITY−REF">/

BBW_SWC_Description/ Const ra int s / TimingConstraints / Execution Order/EO_BrakeActuatorLDM</DIRECT−SUCCESSOR−REF>

159 </DIRECT−SUCCESSOR−REFS>160 <EXECUTABLE−REF DEST="RUNNABLE−ENTITY">/BBW_SWC_Description/

SwComponents/ABS_T_Information/ABS_T//ABS_T</EXECUTABLE−REF>161 </EOC−EXECUTABLE−ENTITY−REF>162 <EOC−EXECUTABLE−ENTITY−REF UUID=" ">163 <SHORT−NAME>EO_BrakeActuatorLDM</SHORT−NAME>164 <EXECUTABLE−REF DEST="RUNNABLE−ENTITY">/BBW_SWC_Description/

SwComponents/BrakeActuatorLDM_Information/BrakeActuatorLDM//BrakeActuatorLDM</EXECUTABLE−REF>

165 </EOC−EXECUTABLE−ENTITY−REF>166 <EOC−EXECUTABLE−ENTITY−REF S=" ">167 <SHORT−NAME>EO_BrakePedalLDM_T</SHORT−NAME>168 <DIRECT−SUCCESSOR−REFS>169 <DIRECT−SUCCESSOR−REF DEST="EOC−EXECUTABLE−ENTITY−REF">/

BBW_SWC_Description/ Const ra int s / TimingConstraints / Execution Order/EO_BrakeTorqMap</DIRECT−SUCCESSOR−REF>


SwComponents/BrakePedalLDM_T_Information/BrakePedalLDM_T//BrakePedalLDM_T</EXECUTABLE−REF>

172 </EOC−EXECUTABLE−ENTITY−REF>173 <EOC−EXECUTABLE−ENTITY−REF>174 <SHORT−NAME>EO_BrakeTorqMap</SHORT−NAME>175 <DIRECT−SUCCESSOR−REFS>176 <DIRECT−SUCCESSOR−REF DEST="EOC−EXECUTABLE−ENTITY−REF">/

BBW_SWC_Description/ Const ra int s / TimingConstraints / Execution Order/EO_GlobalBrakeController</DIRECT−SUCCESSOR−REF>

XVII

A. Appendix 1


SwComponents/BrakeTorqMap_Information/BrakeTorqMap//BrakeTorqMap</EXECUTABLE−REF>

179 </EOC−EXECUTABLE−ENTITY−REF>180 <EOC−EXECUTABLE−ENTITY−REF>181 <SHORT−NAME>EO_GlobalBrakeController</SHORT−NAME>182 <DIRECT−SUCCESSOR−REFS>183 <DIRECT−SUCCESSOR−REF DEST="EOC−EXECUTABLE−ENTITY−REF">/

BBW_SWC_Description/ Const ra int s / TimingConstraints / Execution Order/EO_ABS_T</DIRECT−SUCCESSOR−REF>


SwComponents/ GlobalBrakeContro l l e r_Informat ion / Globa lBrakeContro l l e r //Globa lBrakeContro l l e r</EXECUTABLE−REF>

186 </EOC−EXECUTABLE−ENTITY−REF>187 </ORDERED−ELEMENTS>188 </EXECUTION−ORDER−CONSTRAINT>189 <LATENCY−TIMING−CONSTRAINT UUID=" ">190 <SHORT−NAME>LatencyConstraint_RR</SHORT−NAME>191 <LATENCY−CONSTRAINT−TYPE>REACTION</LATENCY−CONSTRAINT−TYPE>192 <SCOPE−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/

BBW_SWC_Description/ EventChains //EC_Sequence_RR</SCOPE−REF>193 <MAXIMUM>194 <CSE−CODE>20</CSE−CODE>195 </MAXIMUM>196 </LATENCY−TIMING−CONSTRAINT>197 <PERIODIC−EVENT−TRIGGERING UUID=" ">198 <SHORT−NAME>Periodic_Constraint_11</SHORT−NAME>199 <EVENT−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_ABS_RR_Pt</EVENT−REF>200 <PERIOD>201 <CSE−CODE>5</CSE−CODE>202 </PERIOD>203 </PERIODIC−EVENT−TRIGGERING>204 </TIMING−REQUIREMENTS>205 </SWC−TIMING>206 </ELEMENTS>207 </AR−PACKAGE>208 <AR−PACKAGE UUID=" ">209 <SHORT−NAME>EcuResource</SHORT−NAME>210 <AR−PACKAGES>211 <AR−PACKAGE UUID=" ">212 <SHORT−NAME>HwCategory</SHORT−NAME>213 <ELEMENTS>214 <HW−CATEGORY S=" " UUID=" ">215 <SHORT−NAME>Process ingUni t</SHORT−NAME>216 <CATEGORY />217 <HW−ATTRIBUTE−DEFS>218 <HW−ATTRIBUTE−DEF>219 <SHORT−NAME>FrequencyHz</SHORT−NAME>220 <CATEGORY />221 <IS−REQUIRED>true</IS−REQUIRED>222 </HW−ATTRIBUTE−DEF>223 </HW−ATTRIBUTE−DEFS>224 </HW−CATEGORY>225 </ELEMENTS>226 </AR−PACKAGE>227 <AR−PACKAGE UUID=" ">228 <SHORT−NAME>HwElement</SHORT−NAME>229 <ELEMENTS>230 <HW−ELEMENT>231 <SHORT−NAME>CPU0</SHORT−NAME>232 <CATEGORY>CPU</CATEGORY>233 <HW−TYPE−REF DEST="HW−TYPE">/BBW_SWC_Description/ EcuResource /

HwType/QuartzCPU0</HW−TYPE−REF>234 <HW−CATEGORY−REFS>235 <HW−CATEGORY−REF DEST="HW−CATEGORY">/BBW_SWC_Description/

EcuResource /HwCategory/ Proces s ingUni t</HW−CATEGORY−REF>236 </HW−CATEGORY−REFS>

XVIII

A. Appendix 1

237 </HW−ELEMENT>238 <HW−ELEMENT>239 <SHORT−NAME>CPU1</SHORT−NAME>240 <CATEGORY>CPU</CATEGORY>241 <HW−TYPE−REF DEST="HW−TYPE">/BBW_SWC_Description/ EcuResource /


EcuResource /HwCategory/ Proces s ingUni t</HW−CATEGORY−REF>244 </HW−CATEGORY−REFS>245 </HW−ELEMENT>246 <HW−ELEMENT UUID=" ">247 <SHORT−NAME>CPU2</SHORT−NAME>248 <CATEGORY>CPU</CATEGORY>249 <HW−TYPE−REF DEST="HW−TYPE">/BBW_SWC_Description/ EcuResource /


EcuResource /HwCategory/ Proces s ingUni t</HW−CATEGORY−REF>252 </HW−CATEGORY−REFS>253 </HW−ELEMENT>254 </ELEMENTS>255 </AR−PACKAGE>256 <AR−PACKAGE>257 <SHORT−NAME>HwType</SHORT−NAME>258 <ELEMENTS>259 <HW−TYPE>260 <SHORT−NAME>QuartzCPU0</SHORT−NAME>261 <HW−ATTRIBUTE−VALUES>262 <HW−ATTRIBUTE−VALUE>263 <V BLUEPRINT−VALUE=" ">3 .0 E8</V>264 </HW−ATTRIBUTE−VALUE>265 </HW−ATTRIBUTE−VALUES>266 </HW−TYPE>267 <HW−TYPE>268 <SHORT−NAME>QuartzCPU1</SHORT−NAME>269 <HW−ATTRIBUTE−VALUES>270 <HW−ATTRIBUTE−VALUE>271 <V BLUEPRINT−VALUE=" ">3 .0 E8</V>272 </HW−ATTRIBUTE−VALUE>273 </HW−ATTRIBUTE−VALUES>274 </HW−TYPE>275 <HW−TYPE>276 <SHORT−NAME>QuartzCPU2</SHORT−NAME>277 <HW−ATTRIBUTE−VALUES>278 <HW−ATTRIBUTE−VALUE>279 <V BLUEPRINT−VALUE=" ">3 .0 E8</V>280 </HW−ATTRIBUTE−VALUE>281 </HW−ATTRIBUTE−VALUES>282 </HW−TYPE>283 </ELEMENTS>284 </AR−PACKAGE>285 </AR−PACKAGES>286 </AR−PACKAGE>287 <AR−PACKAGE>288 <SHORT−NAME>EventChains</SHORT−NAME>289 <ELEMENTS>290 <SWC−TIMING>291 <TIMING−DESCRIPTIONS>292 <TIMING−DESCRIPTION−EVENT−CHAIN UUID=" ">293 <SHORT−NAME>EC_1_FL</SHORT−NAME>294 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_BrakePedalLDM</STIMULUS−REF>295 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /EventBrakeTorqueMap</RESPONSE−REF>296 </TIMING−DESCRIPTION−EVENT−CHAIN>297 <TIMING−DESCRIPTION−EVENT−CHAIN UUID=" ">298 <SHORT−NAME>EC_1_FR</SHORT−NAME>299 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_BrakePedalLDM</STIMULUS−REF>

XIX

A. Appendix 1

300 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/BBW_SWC_Description/ EventChains / Events /EventBrakeTorqueMap</RESPONSE−REF>

301 </TIMING−DESCRIPTION−EVENT−CHAIN>302 <TIMING−DESCRIPTION−EVENT−CHAIN>303 <SHORT−NAME>EC_1_RL</SHORT−NAME>304 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/


BBW_SWC_Description/ EventChains / Events /EventBrakeTorqueMap</RESPONSE−REF>306 </TIMING−DESCRIPTION−EVENT−CHAIN>307 <TIMING−DESCRIPTION−EVENT−CHAIN>308 <SHORT−NAME>EC_1_RR</SHORT−NAME>309 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/


BBW_SWC_Description/ EventChains / Events /EventBrakeTorqueMap</RESPONSE−REF>311 </TIMING−DESCRIPTION−EVENT−CHAIN>312 <TIMING−DESCRIPTION−EVENT−CHAIN>313 <SHORT−NAME>EC_2_FL</SHORT−NAME>314 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /EventBrakeTorqueMap</STIMULUS−REF>315 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events / Event_GlobalBrakeControl ler</RESPONSE−REF>

316 </TIMING−DESCRIPTION−EVENT−CHAIN>317 <TIMING−DESCRIPTION−EVENT−CHAIN UUID=" ">318 <SHORT−NAME>EC_2_FR</SHORT−NAME>319 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/



321 </TIMING−DESCRIPTION−EVENT−CHAIN>322 <TIMING−DESCRIPTION−EVENT−CHAIN S=" ">323 <SHORT−NAME>EC_2_RL</SHORT−NAME>324 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/



326 </TIMING−DESCRIPTION−EVENT−CHAIN>327 <TIMING−DESCRIPTION−EVENT−CHAIN>328 <SHORT−NAME>EC_2_RR</SHORT−NAME>329 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/



331 </TIMING−DESCRIPTION−EVENT−CHAIN>332 <TIMING−DESCRIPTION−EVENT−CHAIN>333 <SHORT−NAME>EC_3_FL</SHORT−NAME>334 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events / Event_GlobalBrakeControl ler</STIMULUS−REF>

335 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/BBW_SWC_Description/ EventChains / Events /Event_ABS_FL_Pt</RESPONSE−REF>

336 </TIMING−DESCRIPTION−EVENT−CHAIN>337 <TIMING−DESCRIPTION−EVENT−CHAIN S=" ">338 <SHORT−NAME>EC_3_FR</SHORT−NAME>339 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/


340 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/BBW_SWC_Description/ EventChains / Events /Event_ABS_FR_Pt</RESPONSE−REF>

341 </TIMING−DESCRIPTION−EVENT−CHAIN>342 <TIMING−DESCRIPTION−EVENT−CHAIN>343 <SHORT−NAME>EC_3_RL</SHORT−NAME>344 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/


XX

A. Appendix 1

345 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/BBW_SWC_Description/ EventChains / Events /Event_ABS_RL_Pt</RESPONSE−REF>

346 </TIMING−DESCRIPTION−EVENT−CHAIN>347 <TIMING−DESCRIPTION−EVENT−CHAIN>348 <SHORT−NAME>EC_3_RR</SHORT−NAME>349 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/


350 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/BBW_SWC_Description/ EventChains / Events /Event_ABS_RR_Pt</RESPONSE−REF>

351 </TIMING−DESCRIPTION−EVENT−CHAIN>352 <TIMING−DESCRIPTION−EVENT−CHAIN>353 <SHORT−NAME>EC_4_FL</SHORT−NAME>354 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_ABS_FL_Pt</STIMULUS−REF>355 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_FL</RESPONSE−REF>356 </TIMING−DESCRIPTION−EVENT−CHAIN>357 <TIMING−DESCRIPTION−EVENT−CHAIN UUID=" ">358 <SHORT−NAME>EC_4_FR</SHORT−NAME>359 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_ABS_FR_Pt</STIMULUS−REF>360 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_FR</RESPONSE−REF>361 </TIMING−DESCRIPTION−EVENT−CHAIN>362 <TIMING−DESCRIPTION−EVENT−CHAIN>363 <SHORT−NAME>EC_4_RL</SHORT−NAME>364 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_ABS_RL_Pt</STIMULUS−REF>365 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_RL</RESPONSE−REF>366 </TIMING−DESCRIPTION−EVENT−CHAIN>367 <TIMING−DESCRIPTION−EVENT−CHAIN>368 <SHORT−NAME>EC_4_RR</SHORT−NAME>369 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_ABS_RR_Pt</STIMULUS−REF>370 <RESPONSE−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/

BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_RR</RESPONSE−REF>371 </TIMING−DESCRIPTION−EVENT−CHAIN>372 <TIMING−DESCRIPTION−EVENT−CHAIN>373 <SHORT−NAME>EC_Sequence_FL</SHORT−NAME>374 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/


BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_FL</RESPONSE−REF>376 <SEGMENT−REFS>377 <SEGMENT−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/

BBW_SWC_Description/ EventChains //EC_1_FL</SEGMENT−REF>378 <SEGMENT−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/



BBW_SWC_Description/ EventChains //EC_4_FL</SEGMENT−REF>381 </SEGMENT−REFS>382 </TIMING−DESCRIPTION−EVENT−CHAIN>383 <TIMING−DESCRIPTION−EVENT−CHAIN>384 <SHORT−NAME>EC_Sequence_FR</SHORT−NAME>385 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/


BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_FR</RESPONSE−REF>387 <SEGMENT−REFS>388 <SEGMENT−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/

BBW_SWC_Description/ EventChains //EC_1_FR</SEGMENT−REF>389 <SEGMENT−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/



XXI

A. Appendix 1

BBW_SWC_Description/ EventChains //EC_4_FR</SEGMENT−REF>392 </SEGMENT−REFS>393 </TIMING−DESCRIPTION−EVENT−CHAIN>394 <TIMING−DESCRIPTION−EVENT−CHAIN>395 <SHORT−NAME>EC_Sequence_RL</SHORT−NAME>396 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/


BBW_SWC_Description/ EventChains / Events /Event_ABS_RL_Pt</RESPONSE−REF>398 <SEGMENT−REFS>399 <SEGMENT−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/

BBW_SWC_Description/ EventChains //EC_1_RL</SEGMENT−REF>400 <SEGMENT−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/



BBW_SWC_Description/ EventChains //EC_4_RL</SEGMENT−REF>403 </SEGMENT−REFS>404 </TIMING−DESCRIPTION−EVENT−CHAIN>405 <TIMING−DESCRIPTION−EVENT−CHAIN>406 <SHORT−NAME>EC_Sequence_RR</SHORT−NAME>407 <STIMULUS−REF DEST="TD−EVENT−SWC−INTERNAL−BEHAVIOR">/


BBW_SWC_Description/ EventChains / Events /Event_pLDM_Brake_RR</RESPONSE−REF>409 <SEGMENT−REFS>410 <SEGMENT−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/

BBW_SWC_Description/ EventChains //EC_1_RR</SEGMENT−REF>411 <SEGMENT−REF DEST="TIMING−DESCRIPTION−EVENT−CHAIN">/



BBW_SWC_Description/ EventChains //EC_4_RR</SEGMENT−REF>414 </SEGMENT−REFS>415 </TIMING−DESCRIPTION−EVENT−CHAIN>416 </TIMING−DESCRIPTIONS>417 </SWC−TIMING>418 <SWC−TIMING>419 <SHORT−NAME>Events</SHORT−NAME>420 <TIMING−DESCRIPTIONS>421 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">422 <SHORT−NAME>EventBrakeTorqueMap</SHORT−NAME>423 <COMPONENT−IREF>424 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/pBrakeTorqueMap</TARGET−COMPONENT−REF>

425 </COMPONENT−IREF>426 <RUNNABLE−REF DEST="RUNNABLE−ENTITY">/BBW_SWC_Description/

SwComponents/BrakeTorqMap_Information/BrakeTorqMap//BrakeTorqMap</RUNNABLE−REF>427 <TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>RUNNABLE−ENTITY−ACTIVATED</

TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>428 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>429 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">430 <SHORT−NAME>Event_ABS_FL_Pt</SHORT−NAME>431 <COMPONENT−IREF>432 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/ABS_FL_Pt</TARGET−COMPONENT−REF>


SwComponents/ABS_T_Information/ABS_T//ABS_T</RUNNABLE−REF>435 <TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>RUNNABLE−ENTITY−ACTIVATED</

TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>436 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>437 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">438 <SHORT−NAME>Event_ABS_FR_Pt</SHORT−NAME>439 <COMPONENT−IREF>440 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

XXII

A. Appendix 1

BBW_SWC_Description/ SwCompossitions /RootSwComposition/ABS_FR_Pt</TARGET−COMPONENT−REF>



TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>444 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>445 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">446 <SHORT−NAME>Event_ABS_RL_Pt</SHORT−NAME>447 <COMPONENT−IREF>448 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/ABS_RL_Pt</TARGET−COMPONENT−REF>



TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>452 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>453 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">454 <SHORT−NAME>Event_ABS_RR_Pt</SHORT−NAME>455 <COMPONENT−IREF>456 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/ABS_RR_Pt</TARGET−COMPONENT−REF>



TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>460 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>461 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">462 <SHORT−NAME>Event_BrakePedalLDM</SHORT−NAME>463 <COMPONENT−IREF>464 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/pBrakePedalLDM</TARGET−COMPONENT−REF>


SwComponents/BrakePedalLDM_T_Information/BrakePedalLDM_T//BrakePedalLDM_T</RUNNABLE−REF>

467 <TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>RUNNABLE−ENTITY−ACTIVATED</TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>

468 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>469 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">470 <SHORT−NAME>Event_GlobalBrakeControl ler</SHORT−NAME>471 <COMPONENT−IREF>472 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/ pGloba lBrakeContro l l e r</TARGET−COMPONENT−REF>


SwComponents/ GlobalBrakeContro l l e r_Informat ion / Globa lBrakeContro l l e r //Globa lBrakeContro l l e r</RUNNABLE−REF>

475 <TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>RUNNABLE−ENTITY−ACTIVATED</TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>

476 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>477 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">478 <SHORT−NAME>Event_pLDM_Brake_FL</SHORT−NAME>479 <COMPONENT−IREF>480 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/pLDM_Brake_FL</TARGET−COMPONENT−REF>


SwComponents/BrakeActuatorLDM_Information/BrakeActuatorLDM//BrakeActuatorLDM</RUNNABLE−REF>

483 <TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>RUNNABLE−ENTITY−TERMINATED</TD−EVENT−SWC−INTERNAL−BEHAVIOR−TYPE>

XXIII

A. Appendix 1

484 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>485 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">486 <SHORT−NAME>Event_pLDM_Brake_FR</SHORT−NAME>487 <COMPONENT−IREF>488 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/pLDM_Brake_FR</TARGET−COMPONENT−REF>




492 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>493 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">494 <SHORT−NAME>Event_pLDM_Brake_RL</SHORT−NAME>495 <COMPONENT−IREF>496 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/pLDM_Brake_RL</TARGET−COMPONENT−REF>




500 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>501 <TD−EVENT−SWC−INTERNAL−BEHAVIOR UUID=" ">502 <SHORT−NAME>Event_pLDM_Brake_RR</SHORT−NAME>503 <COMPONENT−IREF>504 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE">/

BBW_SWC_Description/ SwCompossitions /RootSwComposition/pLDM_Brake_RR</TARGET−COMPONENT−REF>




508 </TD−EVENT−SWC−INTERNAL−BEHAVIOR>509 </TIMING−DESCRIPTIONS>510 </SWC−TIMING>511 </ELEMENTS>512 </AR−PACKAGE>513 <AR−PACKAGE>514 <SHORT−NAME>Mapping</SHORT−NAME>515 <ADMIN−DATA>516 <SDGS>517 <SDG GID=" _convers ion ">518 <SDG GID="PROCESS−TO−MACHINE−MAPPING−SET">519 <SDG GID="PROCESS−TO−MACHINE−MAPPINGS">520 <SDG GID="PROCESS−TO−MACHINE−MAPPING" />521 <SD GID=" _mixed " />522 </SDG>523 <SD GID=" _mixed " />524 </SDG>525 <SD GID=" _path ">PROCESS−TO−MACHINE−MAPPING−SET@0/ELEMENTS@2</SD>526 <SD GID=" _target ">org . artop . aa l . autosar4430</SD>527 </SDG>528 </SDGS>529 </ADMIN−DATA>530 <ELEMENTS>531 <SWC−BSW−MAPPING>532 <RUNNABLE−MAPPINGS>533 <SWC−BSW−RUNNABLE−MAPPING>534 <SWC−RUNNABLE−REF DEST="RUNNABLE−ENTITY">/BBW_SWC_Description/

SwComponents/ABS_T_Information/ABS_T//ABS_T</SWC−RUNNABLE−REF>535 </SWC−BSW−RUNNABLE−MAPPING>536 </RUNNABLE−MAPPINGS>537 </SWC−BSW−MAPPING>

XXIV

A. Appendix 1

538 </ELEMENTS>539 </AR−PACKAGE>540 <AR−PACKAGE>541 <SHORT−NAME>OS</SHORT−NAME>542 <ELEMENTS>543 <SYSTEM>544 <SHORT−NAME>MICROSAR</SHORT−NAME>545 <CATEGORY>Operating System</CATEGORY>546 </SYSTEM>547 </ELEMENTS>548 </AR−PACKAGE>549 <AR−PACKAGE UUID=" ">550 <SHORT−NAME>SwComponents</SHORT−NAME>551 <AR−PACKAGES>552 <AR−PACKAGE>553 <SHORT−NAME>ABS_T_Information</SHORT−NAME>554 <ELEMENTS>555 <APPLICATION−SW−COMPONENT−TYPE>556 <SHORT−NAME>ABS_T</SHORT−NAME>557 <INTERNAL−BEHAVIORS>558 <SWC−INTERNAL−BEHAVIOR UUID=" ">559 <SHORT−NAME />560 <EVENTS>561 <TIMING−EVENT S=" " UUID=" ">562 <SHORT−NAME>stimulus_5ms</SHORT−NAME>563 <ADMIN−DATA>564 <SDGS>565 <SDG GID=" _convers ion ">566 <SDG GID="OFFSET">567 <SD GID=" _mixed ">0 .0</SD>568 </SDG>569 <SD GID=" _path ">OFFSET@3/</SD>570 <SD GID=" _target ">org . artop . aa l . autosar4460</SD>571 </SDG>572 </SDGS>573 </ADMIN−DATA>574 <START−ON−EVENT−REF DEST="RUNNABLE−ENTITY">/

BBW_SWC_Description/SwComponents/ABS_T_Information/ABS_T//ABS_T</START−ON−EVENT−REF>

575 <PERIOD>0.005</PERIOD>576 </TIMING−EVENT>577 </EVENTS>578 <RUNNABLES>579 <RUNNABLE−ENTITY>580 <SHORT−NAME>ABS_T</SHORT−NAME>581 <MINIMUM−START−INTERVAL>0.0</MINIMUM−START−INTERVAL>582 <SYMBOL />583 </RUNNABLE−ENTITY>584 </RUNNABLES>585 </SWC−INTERNAL−BEHAVIOR>586 </INTERNAL−BEHAVIORS>587 </APPLICATION−SW−COMPONENT−TYPE>588 </ELEMENTS>589 </AR−PACKAGE>590 <AR−PACKAGE>591 <SHORT−NAME>BrakeActuatorLDM_Information</SHORT−NAME>592 <ELEMENTS>593 <APPLICATION−SW−COMPONENT−TYPE S=" " UUID=" ">594 <SHORT−NAME>BrakeActuatorLDM</SHORT−NAME>595 <INTERNAL−BEHAVIORS>596 <SWC−INTERNAL−BEHAVIOR>597 <EVENTS>598 <TIMING−EVENT>599 <SHORT−NAME>stimulus_6ms</SHORT−NAME>600 <ADMIN−DATA>601 <SDGS>602 <SDG GID=" _convers ion ">603 <SDG GID="OFFSET">604 <SD GID=" _mixed ">0 .0</SD>605 </SDG>

XXV

A. Appendix 1

606 <SD GID=" _path ">OFFSET@3/</SD>607 <SD GID=" _target ">org . artop . aa l . autosar4460</SD>608 </SDG>609 </SDGS>610 </ADMIN−DATA>611 <START−ON−EVENT−REF DEST="RUNNABLE−ENTITY">/

BBW_SWC_Description/SwComponents/BrakeActuatorLDM_Information/BrakeActuatorLDM//BrakeActuatorLDM</START−ON−EVENT−REF>

612 <PERIOD>0.006</PERIOD>613 </TIMING−EVENT>614 </EVENTS>615 <RUNNABLES>616 <RUNNABLE−ENTITY S=" ">617 <SHORT−NAME>BrakeActuatorLDM</SHORT−NAME>618 <MINIMUM−START−INTERVAL>0.0</MINIMUM−START−INTERVAL>619 </RUNNABLE−ENTITY>620 </RUNNABLES>621 </SWC−INTERNAL−BEHAVIOR>622 </INTERNAL−BEHAVIORS>623 </APPLICATION−SW−COMPONENT−TYPE>624 </ELEMENTS>625 </AR−PACKAGE>626 <AR−PACKAGE>627 <SHORT−NAME>BrakePedalLDM_T_Information</SHORT−NAME>628 <ELEMENTS>629 <APPLICATION−SW−COMPONENT−TYPE S=" " UUID=" ">630 <SHORT−NAME>BrakePedalLDM_T</SHORT−NAME>631 <INTERNAL−BEHAVIORS>632 <SWC−INTERNAL−BEHAVIOR>633 <EVENTS>634 <TIMING−EVENT>635 <SHORT−NAME>stimulus_2ms</SHORT−NAME>636 <ADMIN−DATA>637 <SDGS>638 <SDG GID=" _convers ion ">639 <SDG GID="OFFSET">640 <SD GID=" _mixed ">0 .0</SD>641 </SDG>642 <SD GID=" _path ">OFFSET@3/</SD>643 <SD GID=" _target ">org . artop . aa l . autosar4460</SD>644 </SDG>645 </SDGS>646 </ADMIN−DATA>647 <START−ON−EVENT−REF DEST="RUNNABLE−ENTITY">/

BBW_SWC_Description/SwComponents/BrakePedalLDM_T_Information/BrakePedalLDM_T//BrakePedalLDM_T</START−ON−EVENT−REF>

648 <PERIOD>0.002</PERIOD>649 </TIMING−EVENT>650 </EVENTS>651 <RUNNABLES>652 <RUNNABLE−ENTITY>653 <SHORT−NAME>BrakePedalLDM_T</SHORT−NAME>654 <MINIMUM−START−INTERVAL>0.0</MINIMUM−START−INTERVAL>655 <REENTRANCY−LEVEL>MULTICORE−REENTRANT</REENTRANCY−LEVEL>656 </RUNNABLE−ENTITY>657 </RUNNABLES>658 </SWC−INTERNAL−BEHAVIOR>659 </INTERNAL−BEHAVIORS>660 </APPLICATION−SW−COMPONENT−TYPE>661 </ELEMENTS>662 </AR−PACKAGE>663 <AR−PACKAGE>664 <SHORT−NAME>BrakeTorqMap_Information</SHORT−NAME>665 <ELEMENTS>666 <APPLICATION−SW−COMPONENT−TYPE UUID=" ">667 <SHORT−NAME>BrakeTorqMap</SHORT−NAME>668 <SHORT−NAME−PATTERN />669 <INTERNAL−BEHAVIORS>670 <SWC−INTERNAL−BEHAVIOR>671 <EVENTS>

XXVI

A. Appendix 1

672 <TIMING−EVENT UUID=" ">673 <SHORT−NAME>stimulus_3ms</SHORT−NAME>674 <ADMIN−DATA>675 <SDGS>676 <SDG GID=" _convers ion ">677 <SDG GID="OFFSET">678 <SD GID=" _mixed ">0 .0</SD>679 </SDG>680 <SD GID=" _path ">OFFSET@3/</SD>681 <SD GID=" _target ">org . artop . aa l . autosar4460</SD>682 </SDG>683 </SDGS>684 </ADMIN−DATA>685 <START−ON−EVENT−REF DEST="RUNNABLE−ENTITY">/

BBW_SWC_Description/SwComponents/BrakeTorqMap_Information/BrakeTorqMap//BrakeTorqMap</START−ON−EVENT−REF>

686 <PERIOD>0.003</PERIOD>687 </TIMING−EVENT>688 </EVENTS>689 <RUNNABLES>690 <RUNNABLE−ENTITY S=" ">691 <SHORT−NAME>BrakeTorqMap</SHORT−NAME>692 <MINIMUM−START−INTERVAL>0.0</MINIMUM−START−INTERVAL>693 </RUNNABLE−ENTITY>694 </RUNNABLES>695 </SWC−INTERNAL−BEHAVIOR>696 </INTERNAL−BEHAVIORS>697 </APPLICATION−SW−COMPONENT−TYPE>698 </ELEMENTS>699 </AR−PACKAGE>700 <AR−PACKAGE UUID=" ">701 <SHORT−NAME>GlobalBrakeContro l l e r_Informat ion</SHORT−NAME>702 <ELEMENTS>703 <APPLICATION−SW−COMPONENT−TYPE S=" ">704 <SHORT−NAME>Globa lBrakeContro l l e r</SHORT−NAME>705 <CATEGORY />706 <INTERNAL−BEHAVIORS>707 <SWC−INTERNAL−BEHAVIOR>708 <EVENTS>709 <TIMING−EVENT S=" " UUID=" ">710 <SHORT−NAME>stimulus_4ms</SHORT−NAME>711 <ADMIN−DATA>712 <SDGS>713 <SDG GID=" _convers ion ">714 <SDG GID="OFFSET">715 <SD GID=" _mixed ">0 .0</SD>716 </SDG>717 <SD GID=" _path ">OFFSET@3/</SD>718 <SD GID=" _target ">org . artop . aa l . autosar4460</SD>719 </SDG>720 </SDGS>721 </ADMIN−DATA>722 <START−ON−EVENT−REF DEST="RUNNABLE−ENTITY">/

BBW_SWC_Description/SwComponents/ GlobalBrakeContro l l e r_Informat ion /Globa lBrakeContro l l e r // Globa lBrakeContro l l e r</START−ON−EVENT−REF>

723 <PERIOD>0.004</PERIOD>724 </TIMING−EVENT>725 </EVENTS>726 <RUNNABLES>727 <RUNNABLE−ENTITY>728 <SHORT−NAME>Globa lBrakeContro l l e r</SHORT−NAME>729 <MINIMUM−START−INTERVAL>0.0</MINIMUM−START−INTERVAL>730 </RUNNABLE−ENTITY>731 </RUNNABLES>732 </SWC−INTERNAL−BEHAVIOR>733 </INTERNAL−BEHAVIORS>734 </APPLICATION−SW−COMPONENT−TYPE>735 </ELEMENTS>736 </AR−PACKAGE>737 </AR−PACKAGES>

XXVII

A. Appendix 1

738 </AR−PACKAGE>739 <AR−PACKAGE UUID=" ">740 <SHORT−NAME>SwCompossitions</SHORT−NAME>741 <ELEMENTS>742 <COMPOSITION−SW−COMPONENT−TYPE>743 <SHORT−NAME>RootSwComposition</SHORT−NAME>744 <COMPONENTS>745 <SW−COMPONENT−PROTOTYPE>746 <SHORT−NAME>ABS_FL_Pt</SHORT−NAME>747 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/

BBW_SWC_Description/SwComponents/ABS_T_Information/ABS_T</TYPE−TREF>748 </SW−COMPONENT−PROTOTYPE>749 <SW−COMPONENT−PROTOTYPE>750 <SHORT−NAME>ABS_FR_Pt</SHORT−NAME>751 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/

BBW_SWC_Description/SwComponents/ABS_T_Information/ABS_T</TYPE−TREF>752 </SW−COMPONENT−PROTOTYPE>753 <SW−COMPONENT−PROTOTYPE>754 <SHORT−NAME>ABS_RL_Pt</SHORT−NAME>755 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/

BBW_SWC_Description/SwComponents/ABS_T_Information/ABS_T</TYPE−TREF>756 </SW−COMPONENT−PROTOTYPE>757 <SW−COMPONENT−PROTOTYPE>758 <SHORT−NAME>ABS_RR_Pt</SHORT−NAME>759 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/

BBW_SWC_Description/SwComponents/ABS_T_Information/ABS_T</TYPE−TREF>760 </SW−COMPONENT−PROTOTYPE>761 <SW−COMPONENT−PROTOTYPE UUID=" ">762 <SHORT−NAME>pBrakePedalLDM</SHORT−NAME>763 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/

BBW_SWC_Description/SwComponents/BrakePedalLDM_T_Information/BrakePedalLDM_T</TYPE−TREF>

764 </SW−COMPONENT−PROTOTYPE>765 <SW−COMPONENT−PROTOTYPE>766 <SHORT−NAME>pBrakeTorqueMap</SHORT−NAME>767 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/

BBW_SWC_Description/SwComponents/BrakeTorqMap_Information/BrakeTorqMap</TYPE−TREF>

768 </SW−COMPONENT−PROTOTYPE>769 <SW−COMPONENT−PROTOTYPE>770 <SHORT−NAME>pGlobalBrakeContro l l e r</SHORT−NAME>771 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/

BBW_SWC_Description/SwComponents/ GlobalBrakeContro l l e r_Informat ion /Globa lBrakeContro l l e r</TYPE−TREF>

772 </SW−COMPONENT−PROTOTYPE>773 <SW−COMPONENT−PROTOTYPE>774 <SHORT−NAME>pLDM_Brake_FL</SHORT−NAME>775 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/

BBW_SWC_Description/SwComponents/BrakeActuatorLDM_Information/BrakeActuatorLDM</TYPE−TREF>

776 </SW−COMPONENT−PROTOTYPE>777 <SW−COMPONENT−PROTOTYPE>778 <SHORT−NAME>pLDM_Brake_FR</SHORT−NAME>779 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/


780 </SW−COMPONENT−PROTOTYPE>781 <SW−COMPONENT−PROTOTYPE>782 <SHORT−NAME>pLDM_Brake_RL</SHORT−NAME>783 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/


784 </SW−COMPONENT−PROTOTYPE>785 <SW−COMPONENT−PROTOTYPE>786 <SHORT−NAME>pLDM_Brake_RR</SHORT−NAME>787 <TYPE−TREF DEST="APPLICATION−SW−COMPONENT−TYPE">/


788 </SW−COMPONENT−PROTOTYPE>789 </COMPONENTS>

XXVIII

A. Appendix 1

790 </COMPOSITION−SW−COMPONENT−TYPE>791 </ELEMENTS>792 </AR−PACKAGE>793 </AR−PACKAGES>794 </AR−PACKAGE>795 </AR−PACKAGES>796 <AR−PACKAGE UUID=" 1730698 a−4ed2−4ab4−bb7d−dfdafdbd72ad ">797 <SHORT−NAME>AUTOSAR_Project</SHORT−NAME>798 <AR−PACKAGES>799 <AR−PACKAGE UUID=" 43 d54b22−1b52−49a6−b3a1−dd9c75d52f7f ">800 <SHORT−NAME>BaseTypes</SHORT−NAME>801 <CATEGORY>STANDARD</CATEGORY>802 <ELEMENTS>803 <SW−BASE−TYPE UUID=" c6a5ae11−6097−4e64−8ced−71efc1e94d2d ">804 <SHORT−NAME>Base_16 . 0 b i t</SHORT−NAME>805 <CATEGORY>FIXED_LENGTH</CATEGORY>806 <BASE−TYPE−SIZE>16</BASE−TYPE−SIZE>807 <BASE−TYPE−ENCODING x s i : n i l=" t rue " />808 <MEM−ALIGNMENT>0</MEM−ALIGNMENT>809 <BYTE−ORDER>MOST−SIGNIFICANT−BYTE−LAST</BYTE−ORDER>810 <NATIVE−DECLARATION x s i : n i l=" t rue " />811 </SW−BASE−TYPE>812 <SW−BASE−TYPE UUID=" 9aa2944d−cac5−4a7f−8809−6584000192a8 ">813 <SHORT−NAME>Base_8 . 0 b i t</SHORT−NAME>814 <CATEGORY>FIXED_LENGTH</CATEGORY>815 <BASE−TYPE−SIZE>8</BASE−TYPE−SIZE>816 <BASE−TYPE−ENCODING x s i : n i l=" t rue " />817 <MEM−ALIGNMENT>0</MEM−ALIGNMENT>818 <BYTE−ORDER>MOST−SIGNIFICANT−BYTE−LAST</BYTE−ORDER>819 <NATIVE−DECLARATION x s i : n i l=" t rue " />820 </SW−BASE−TYPE>821 </ELEMENTS>822 </AR−PACKAGE>823 <AR−PACKAGE UUID=" 95 f01a97−98dc−4628−a135−88b77aa79072 ">824 <SHORT−NAME>CompuMethods</SHORT−NAME>825 <CATEGORY>STANDARD</CATEGORY>826 </AR−PACKAGE>827 <AR−PACKAGE UUID=" 4470200 c−00c0−42b2−8065−7453a59ae345 ">828 <SHORT−NAME>Const ra int s</SHORT−NAME>829 <ELEMENTS>830 <SWC−TIMING UUID=" 44 de6e2c−1f99−4464−a9df−976a4253c137 ">831 <SHORT−NAME>TimingConstraints</SHORT−NAME>832 <TIMING−REQUIREMENTS>833 <EXECUTION−TIME−CONSTRAINT UUID=" 69 dc11c3−f8eb−4396−a3b5−6af3678bb201

">834 <SHORT−NAME>GrossUpper</SHORT−NAME>835 </EXECUTION−TIME−CONSTRAINT>836 </TIMING−REQUIREMENTS>837 </SWC−TIMING>838 </ELEMENTS>839 </AR−PACKAGE>840 </AR−PACKAGES>841 </AR−PACKAGE>842 </AUTOSAR>

XXIX

Documents

Timing Veriﬁcation of Application Soft- ware in Multi-Core