How to enrich AUTOSAR based design processes with enabled … · Autosar World wide private...
Transcript of How to enrich AUTOSAR based design processes with enabled … · Autosar World wide private...
How to enrich AUTOSAR baseddesign processes
with enabledSystem-level Analysis
Werner Damm
08.06.2008 2 © Werner Damm , OFFIS
The Challenge
To have the cake and eat it:
Maintain target-hardware independence of capturing function networks
re-use across multiple platforms!
Yet assess realizability of new functions early (but this is dependent on the target … )
frontloading!
08.06.2008 3 © Werner Damm , OFFIS
Structure of Talk
Key Benefits of Autosar
Rich components
Speeds integration technology
Rich Component Based Design
Adding Speeds to Autosar: what it takes
08.06.2008 4 © Werner Damm , OFFIS
Drivers for Change in automotive embedded systems developmentFlexibility
Decouple growth rate of #functions from growth rate of #electronic componentsFreedom in choosing boundary of in-house and external development
AdaptabilityTowards emerging technologiesTowards emerging hardware platformsMaintainability : at life-time
CostDecouple growth of #functions from growth rate of development costsDecouple growth rate of number of supported platforms from development costs
QualityMaintain/Improve Quality while allowing growth of #functions
08.06.2008 5 © Werner Damm , OFFIS
Anticipated Changes in ProcessesStrong push to virtual subsystem models Target
independentTopic in Autosar
Strong push towards component based developmentTopic in AutosarRequires component characterizations dealing with non-functional aspects (e.g. real-time, safety, ...)
Need to support safety standardsto support IEC 61508 customized to automotive domain: ISO WD 26 26 2 – compliant processes
Deployment analysis capabilities will be keycompetence
for price-competetive offerings of tier 1 supliersFor realizability analysis of new functions for innovatorOEMs
08.06.2008 6 © Werner Damm , OFFIS
Autosar
World wide private partnership of automotive OEMs, tier1/tier2 suppliers, SW-houses, vendors to push standardization of E/E architectures with more than 100 partnersStandardized meta-model, release 3.0 available from www.autosar.org
08.06.2008 7 © Werner Damm , OFFIS
Autosar
Decoupling functional design from implementation platform
© Autosar ConsortiumAchievements and exploitation of the AUTOSAR development partnership, Convergence 2006
08.06.2008 8 © Werner Damm , OFFIS
Key Benefits Autosar Design Methodology
Separation of application specification and development from implementation on specific hardware platforms
a key enabler for enhanced cross platform re-use of applicationsallows cost-tuned hardware implementations for the specific set of functions and features integrated in a particular vehicle development.
Supports a stepwise refinement of the overall system designstarting at a coarse grain system topology defined in the systemtemplate stepwise enriched by hardware-related information based on mappings to the ECU network.
The AUTOSAR metamodel gives a formal standardized specification of information required for a functional system design
provides skeleton for additional information to support further aspects of a full system-level analysis. Allows to extend early assessment of key functional requirements by an analysis of non-functional requirements based on an extended AUTOSAR meta-model.
08.06.2008 9 © Werner Damm , OFFIS
Linking and Autosar
08.06.2008 11 © Werner Damm , OFFIS
The StoryRhapsodyTM
SimulinkTM SCADETMSildexTM
Heterogeneous model-based designSemantic integration of industry standard tools
ContractEditor
Transmit(D_out) each 30ms withmax. 7ms jitter
Receive(D_in) each 30ms withmax. 4ms jitter
ContractAssumption Promise
Contract-based multi-criteriasystem-level analysis
AnalysisAnalysing complianceof Autosar Configurations
against vertical assumptions
08.06.2008 12 © Werner Damm , OFFIS
Technical Highlights of the IP Speeds
Speeds providesThe capability of Modeling and Integration of Architectural Abstractions at all System Design Levels for multiple viewpoints including real-time and safetyA Rich Component Model allowing to completely encapsulate functional and non-functional aspects of a design in an assume-guarantee style with cross viewpoint dependencies, including the capability of expressing assumptions on lower design levels captured as architectural abstractionsA harmonized meta-model allowing a semantic integration of industry standard system- and software design toolssupporting rich components based on an open tool integration standard, compatible with the AutosarMetamodelA suite of compositional analysis and design space exploration methods supporting real-time and safety analysis
08.06.2008 13 © Werner Damm , OFFIS
Acknowledgements
This talk represents the collaborative effort of the Speeds consortium
End-users: Airbus, Bosch, Carmeq, EADS, IAI, Knorr-Bremse, MagnaSteyr, Saab
VendorsEsterel Technologies, Extesy, Geensys, Telelogic
Research OrganizationsINRIA, OFFIS, Parades, Verimag
The integrated project Speeds is funded by the European Commission under contract FP6-033471
Rich Components
08.06.2008 15 © Werner Damm , OFFIS
SC - Safety Critical Systems4, March 2008 15
„Rich Components“- Objectives
To provide a characterization of components of automotive electronic components
supporting all phases, levels, and viewpoints of electronic system designAllowing complete re-use (across multiple platforms, across multiple organizations, and/or as part of design libraries)Allowing characterization of allowed/assumed environments of component (for all viewpoints)Basis for (de-facto) standardization, compatible with Autosar Component Model
As basis for tool-independent meta-model for capturing and validating function networks
Supporting semantic based integration of industry standard System & SW design tools (UML, Matlab-Simulink/Stateflow, ASCET, …)Supporting view-point specific and cross viewpoint requirement capturing, modeling, analysis and design
08.06.2008 16 © Werner Damm , OFFIS
SC - Safety Critical Systems16
Rich Component Model
Follows Design by Contract Paradigm
Assumptionsreflect current degree of knowledge of anticipated design contextDetermine boundary conditions on actual design context for each view-point under which component is promising its servicesare decorated with confidence levels
PromisesAre guaranteed if component is used in assumed design context
Organized per viewpointBehaviour, Coordination, Safety, Real-Time, ….But allows specification of cross viewpoint dependencies
Assumed
EL
FL
SL
From/by lower design levels
from neighbors
Promised
From/by higher design levels
to neighbors
HL
08.06.2008 17 © Werner Damm , OFFIS
SC - Safety Critical Systems4, March 2008 17
DCPS
Assumption:Status of vehicle‘ availableevery t ms
Promise:Status(vehicle‘) == braking(p)impliesSignal(Brake(p)) within t‘ ms
Assumption:Distance sensor values davailable every t ms
Promise:<d at t1> less than <d at t0>impliesSignal(Brake) within t‘ ms
…
PBK
PDS
Get statusinformation of vehicle ahead
Get distance informationbased on sensor values
Provide controlcommands
Contracts
08.06.2008 18 © Werner Damm , OFFIS
Adding contracts: ExampleExpressing assumptions on task activation
Use contract editorto identify relevant component and port
Choose patternfrom real-timelibrary to captureassumptions
Here: Activation patternfor periodicsystems
18
08.06.2008 19 © Werner Damm , OFFIS
Adding contracts: ExampleExpressing promise on maximal delay
19
Use contract editorto identify relevant component and port
Choose patternfrom real-timelibrary to captureassumptions
Here: Delay Pattern
Link assumption on task activation to promise on maximal delay
08.06.2008 20 © Werner Damm , OFFIS
20
Heterogenous Rich ComponentsMetamodel Characteristics
Based on SysMLAdded Features
Contracts (Assumptions, Promises)ViewpointsLayers (Functional Network, ECU, Physical Architecture, ..)
Available as Standalone Metamodel Implementationand SysML ProfileEquipped with formal semantics
building on few „semantic atoms“: continuous evolution, discretetransitions, random choicesemantic basis for contract compliance/dominance
a
b?b!
c c
A1A2 for all viewpoints v:
∩ L(A(OutI.v.prj)) ⊆∩ L(A(InI.v.assmi))
SpeedsSemantic Foundation
SpeedsMetamodel
AK
BR
GR SK
LR
component Cbegin view Real-time
interface I beginbegin ……. endend ….
view functional ….begin end C…end
view safetybegin…end
User‘s View: COTS modeling toolsSimulinkTM SCADETMRhapsodyTMSildexTMContractEditor
08.06.2008 22 © Werner Damm , OFFIS
Use Cases supported by Speeds bus
SPEEDS Engineering Bus
Model Repository
Modeling
Tool X
Modeling
Tool Y
Simulink
Rhapsody
SCA
DE
Analysis X
Analysis Y
RT-B
uilder
Simulink
SCA
DE
Rhapsody
Tool Z
SCA
DE D
isplay
Adapter Adapter
ProcessAdvisor
Modeling
Tool X
Use Case 1: Designing Functional Network (Structure) in Tool 1
SYS
F1
F3
F4
F2
Contracts for F3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Contracts for SYS
Contract C:Assumption:
……..Promise:
…..
Contract C’:Assumption:
……..Promise:
…..
Tool 1 – Functional NetworkTool 1 – Functional Network
SYS
F1
F3
F4
F2Contracts for F 3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Contracts for SYS
Contract C:Assumption:
……..Promise:
…..
Contract C’:Assumption:
……..Promise:
…..
Tool 1 – Functional NetworkTool 1 – Functional Network
SYS
F1
F3
F4
F2Contracts for F3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Contracts for SYS
Contract C:Assumption:
……..Promise:
…..
Contract C’:Assumption:
……..Promise:
…..
Classification of contracts w.r.t. viewpoints
Functional BehaviourAssumption:
in1 in range [a..b]in2 in range [a..b]
Promise:out = funct(in1, in2)
Real-TimeAssumption:
every request for sensor values willbe answered within [t0..t1]
Promise:new actuator values will be transmitted every t ms
08.06.2008 23 © Werner Damm , OFFIS
SC - Safety Critical Systems4, March 2008 23
SPEEDS Engineering Bus
Model Repository
Modeling
Tool X
Modeling
Tool Y
Simulink
Rhapsody
SCA
DE
Analysis X
Analysis Y
RT-B
uilder
Simulink
SCA
DE
Rhapsody
Tool Z
SCA
DE D
isplay
Adapter Adapter
ProcessAdvisor
SYS
F1
F3
F4
F2
Contracts for F3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Contracts for SYS
Contract C:Assumption:
……..Promise:
…..
Contract C’:Assumption:
……..Promise:
…..
Use Cases supported by Speeds bus
Simulink
Use Case 2: Designing a Component (Implementation) in Tool 2Tool 2 – Component F3Tool 2 – Component F3
F3Contracts for F 3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
1
Transmissionratio
NinNout
Tout
gear
TinTorqueconverter
2
3
1
2
Ti
Tout
Ne
gear
Nout
turbine torque
F3
1
Transmissionratio
NinNout
Tout
gear
TinTorqueconverter
2
3
1
2
Ti
Tout
Ne
gear
Nout
turbine torque
Contracts for F3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Tool 1 – Functional NetworkTool 1 – Functional Network
SYS
F1
F3
F4
F2Contracts for F 3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Contracts for SYS
Contract C:Assumption:
……..Promise:
…..
Contract C’:Assumption:
……..Promise:
…..
Tool 2 – Component F3Tool 2 – Component F3
F3Contracts for F3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
1
Transmissionratio
NinNout
Tout
gear
TinTorqueconverter
2
3
1
2
Ti
Tout
Ne
gear
Nout
turbine torque
08.06.2008 24 © Werner Damm , OFFIS
SC - Safety Critical Systems4, March 2008 24
SPEEDS Engineering Bus
Model Repository
Modeling
Tool X
Modeling
Tool Y
Simulink
Rhapsody
SCA
DE
Analysis X
Analysis Y
RT-B
uilder
Simulink
SCA
DE
Rhapsody
Tool Z
SCA
DE D
isplay
Adapter Adapter
ProcessAdvisor
SYS
F1
F3
F4
F2
Contracts for F3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Contracts for SYS
Contract C:Assumption:
……..Promise:
…..
Contract C’:Assumption:
……..Promise:
…..
Use Cases supported by Speeds bus
Analysis 1
Use Case 3: Analysis 1 (Compatibility)Tool 2 – Component F3Tool 2 – Component F3
F3Contracts for F 3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
1
Transmissionratio
NinNout
Tout
gear
TinTorqueconverter
2
3
1
2
Ti
Tout
Ne
gear
Nout
turbine torque
Analysis 1 – Compatibility F3 - SYSAnalysis 1 – Compatibility F3 - SYS
Select Components
StructureSYS
F1
F4
F3F2
PortsContracts
C1
ImplementationF3
PortsContracts
Con1
Component 2
Component 1
Con2
C2
Options Analysis
Check Compatibility of ContractsΞ Defined in the Structure DefinitionΞ Defined in the Implementation
Check Compatibility of PortsΞ Defined in the Structure DerfitionΞ Defined in the Implementation
Check ...
F3
1
Transmissionratio
NinNout
Tout
gear
TinTorqueconverter
2
3
1
2
Ti
Tout
Ne
gear
Nout
turbine torque
Contracts for F3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Analysis 1 – Compatibility F3 - SYSAnalysis 1 – Compatibility F3 - SYS
Select Components
StructureSYS
F1
F4
F3F2
PortsContracts
C1
Implementation
F3PortsContracts
Con1
Component 2
Component 1
Con2
C2
Options Analysis
Check Compatibility of ContractsDefined in the Structure DefinitionDefined in the Implementation
Check Compatibility of PortsDefined in the Structure DefinitionDefined in the Implementation
Check ...
Tool 1 – Functional NetworkTool 1 – Functional Network
SYS
F1
F3
F4
F2Contracts for F 3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Contracts for SYS
Contract C:Assumption:
……..Promise:
…..
Contract C’:Assumption:
……..Promise:
…..
08.06.2008 25 © Werner Damm , OFFIS
SC - Safety Critical Systems4, March 2008 25
SPEEDS Engineering Bus
Model Repository
Modeling
Tool X
Modeling
Tool Y
Simulink
Rhapsody
SCA
DE
Analysis X
Analysis Y
RT-B
uilder
Simulink
SCA
DE
Rhapsody
Tool Z
SCA
DE D
isplay
Adapter Adapter
ProcessAdvisor
SYS
F1
F3
F4
F2
Contracts for F3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Contracts for SYS
Contract C:Assumption:
……..Promise:
…..
Contract C’:Assumption:
……..Promise:
…..
Use Cases supported by Speeds bus
Analysis 2
Use Case 4: Analysis 2 (Advanced Analysis Techniques)Tool 1 – Functional NetworkTool 1 – Functional Network
SYS
F1
F3
F4
F2
Contracts for F 3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
Tool 2 – Component F3Tool 2 – Component F3
F3Contracts for F 3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
1
Transmissionratio
NinNout
Tout
gear
TinTorqueconverter
2
3
1
2
Ti
Tout
Ne
gear
Nout
turbine torque
Analysis 2 – SchedulabilityAnalysis 2 – Schedulability
Advanced Analysis Techniques
I2 O2
I1 O1
TDMAschedule
TDMAschedule
TDMAschedule
Supplier X
Function A
Function B
OEM OEM
OEM
OEM
I2 O2
I1 O1
I2 O2
I1 O1
I2 O2I2 O2I2 O2
I1 O1I1 O1I1 O1
TDMAschedule
TDMAschedule
TDMAschedule
Supplier X
Function A
Function B
OEM OEM
OEM
OEM
Analysis 1 – Compatibility F3 - SYSAnalysis 1 – Compatibility F3 - SYS
Select Components
StructureSYS
F1
F4
F3F2
PortsContracts
C1
ImplementationF3
PortsContracts
Con1
Component 2
Component 1
Con2
C2
Options Analysis
Check Compatibility of ContractsΞ Defined in the Structure DefinitionΞ Defined in the Implementation
Check Compatibility of PortsΞ Defined in the Structure DerfitionΞ Defined in the Implementation
Check ...
F3
1
Transmissionratio
NinNout
Tout
gear
TinTorqueconverter
2
3
1
2
Ti
Tout
Ne
gear
Nout
turbine torque
Contracts for F3
Contract C1:Assumption:
……..Promise:
…..
Contract C2:Assumption:
……..Promise:
…..
I2 O2
I1 O1
TDMAschedule
TDMAschedule
TDMAschedule
Supplier X
Function A
Function B
OEM OEM
OEM
OEM
I2 O2
I1 O1
I2 O2
I1 O1
I2 O2I2 O2I2 O2
I1 O1I1 O1I1 O1
TDMAschedule
TDMAschedule
TDMAschedule
Supplier X
Function A
Function B
OEM OEM
OEM
OEM
08.06.2008 26 © Werner Damm , OFFIS
RCM in the Design Process (Focus Real-time)
OEM Supplier
Specification of Functional Network
Design SpaceExploration
DecompositionOf Contracts
Contracts(Ai, Pi)
Guaranteedby OEM
(resp. othersuppliers)
Requirements
Contracts(A, P)
To beGuaranteedby Supplier
Component Design
Final Deployment
08.06.2008 27 © Werner Damm , OFFIS
RCM in the Design Process (Focus Real-time)
OEM Supplier
Specification of Functional Network
Design SpaceExploration
DecompositionOf Contracts
Contracts(Ai, Pi)
Guaranteedby OEM
(resp. othersuppliers)
Requirements
Contracts(A, P)
To beGuaranteedby Supplier
Component Design
Final Deployment
08.06.2008 28 © Werner Damm , OFFIS
System level timinganalysis
Is applied to meta-modelrepresentation of designsat function layerVerifies end-to-endproperties and/or timedsequence diagramsIs based on verticalassumptions (typicallydelay constraints)Assumptions annotatedwith confidence levels
S
DSAK
BRvsvs
dsd
bsp
asp
gdmd
S AK DS BR
S.vs→AK.vs
AK.gd→DS.md
DS.d→AK.ds
AK.bsp→BR.sp
ENV
BR.a[0,50]ms
delay(vs,gd)=[0,8]msdelay(ds,bsp)=[0,5]ms
Vertical assumption
delay(md,d)=[0,1]ms
Vertical assumption
Vertical assumption
End-
to-e
ndde
adlin
e
ConfLevel=high
ConfLevel=highConfLevel=low
ConfLevel=low
delay(DS.d,AK.ds) =[0,6]ms
08.06.2008 29 © Werner Damm , OFFIS
Contract Compatability
Assumptions in contractsassociated with ports constrainallowed environmentsContracts of virtualcommunication componentcharacterize space of viablecommunication architecturesExample use case for contractcompatibility: composition of components coming fromdifferent suppliersExample compatability check:Is contract of component DS compliant to assumptions of communication component
DS
AK
Supplier A
Supplier B
Receive(DS) each 30ms withmax. 8ms jitter
Send(DS) each30ms with max. 3ms jitter
Flexray BackboneCAN
Transmit(DS) each 30ms withmax. 7ms jitter
Receive(DS) each 6ms withmax. 1ms jitter
Receive(DS) each 30ms withmax. 4ms jitter
C1=(A1,P1)
C2=(A2,P2)
VirtualCommunicationComponent
08.06.2008 30 © Werner Damm , OFFIS
SPEEDS – System-level hostedsimulation
SimulinkTM SCADETM
RhapsodyTM
SildexTM
Compiler
SWC1.c
Wrapper
Code generation
SWC2.c
Wrapper
Code generation
SWC3.c
Wrapper
Code generation
SWC4.c
Wrapper
Code generation
08.06.2008 31 © Werner Damm , OFFIS
SC - Safety Critical Systems31
Design Space ExplorationOEM Supplier
Specification of Functional Network
Design SpaceExploration
DecompositionOf Contracts
Contracts(Ai, Pi)
Guaranteedby OEM
(resp. othersuppliers)
Requirements
Contracts(A, P)
To beGuaranteedby Supplier
Component Design
Final Deployment
Analysis of the architecture also w.r.t. other viewpoints, e.g.
Safety
08.06.2008 32 © Werner Damm , OFFIS
Architectureexploration
Given:Partially defined architectureNetwork of functions, partiallyknown by re-use of alreadydesigned components
Early assessment of architectural solutionsContracts to lower layer of abstraction used to definerequirements forimplementation of functionsExpress contracts based on
ExperiencePrevious developmentsModel based estimations
DS AS VS
LS GS MSBA TA LA
S
BR
GR SK
LR
Flexray Backbone
CANDS
AK
08.06.2008 33 © Werner Damm , OFFIS
Architectur exploration – Approach
Establish link betweenvertical assumptions at system level and vertical promises of detailed designCheck dominance
SimulinkTM SCADETM
RhapsodyTM
SildexTM
S AK DS BRS.vs→AK.vs
AK.gd→DS.md
DS.d→AK.ds
AK.bsp→BR.sp
ENV
BR.a[0,50]ms
Requirement
Vertical Assumptionon AK:
AK.vs every 50ms with max. 3ms
jitter
Flexray
S vs
AK
vs
ds
bsp
gd
CAN
S vs
AK
vs
ds
bsp
gd
Vertical Promiseon AK:
AK.vs every 50ms with max. 8ms
jitter
Vertical Promiseon AK:
AK.vs every 50ms with max. 2ms
jitter
Solution 1 Solution 2
08.06.2008 34 © Werner Damm , OFFIS
Assessments of architectural variantssupported by automatic analysismethodsMinimize the number of ECUsRobustness : Often parameters, e.g. WCET, are uncertain. Design optimization has to consider robustness under variations of WCET
Penalty of changes: late integration of new functions induces changes in the already implemented system, but number of changes has to be kept small. Must assess deployment wrt penalty for changes
08.06.2008 35 © Werner Damm , OFFIS
SC - Safety Critical Systems354, March 2008
Creating Deployable Units
OEM Supplier
Specification of Functional Network
Design SpaceExploration
DecompositionOf Contracts
Contracts(Ai, Pi)
Guaranteedby OEM
(resp. othersuppliers)
Requirements
Contracts(A, P)
To beGuaranteedby Supplier
Component Design
Final Deployment
ContractsReal-time View
Assm: ...Promise:
„Local End-to-End Deadlines“
08.06.2008 36 © Werner Damm , OFFIS
SC - Safety Critical Systems4, March 2008 36
Generating requirements for suppliersDesign space exploration returns class of feasible architecture
After finding architecture and communication matrix (used slots in TDMA rounds on bus and ECUs), generate timing requirements for outsourced software components:
Requirements for these delivered to supplier as part of contract
Assume class of architectureAssume allowed behavior of environment (e.g. activation pattern)Promise maximal delay and jitter
Enables incremental integration by OEM based on contracts
If supplier fulfills its contract, integration will be successfulAllows supplier to develop function in isolation without the need to consider functions coming from OEM or other suppliers
08.06.2008 37 © Werner Damm , OFFIS
Getting the best of both worlds
RCM supports system leveldesign
RCM enables combination of model based design and contract-based reasoning
AUTOSAR starts on functionalnetwork level
Combination of both covers theentire V-cycle starting fromrequirements and ending in implementation of operational architecture
SC - Safety Critical Systems4, March 2008 37
Requirements
System level design
Detailed design
Implementation Arch.
AUTOSAR Operational Architecture – OS, COM
AUTOSARApplication SW Arch.
BSWArch.
HWArch.
EnvironmentM
odel
08.06.2008 38 © Werner Damm , OFFIS
AUTOSAR enabled system level analysisSystem level analysisis based on verticalassumption, e.g. response times of components
AUTOSAR definesoperational architecture
Special tailoredanalysis can be usedto verify correctnessof assumptions usedfor system analysis(e.g. schedulinganalysis) SC - Safety Critical Systems4, March 2008 38
SimulinkTM SCADETM
RhapsodyTM
SildexTM
S AK DS BRS.vs→AK.vs
AK.gd→DS.md
DS.d→AK.ds
AK.bsp→BR.sp
ENV
BR.a[0,50]ms
RequirementVerticalAssumption3
VerticalAssumption2
VerticalAssumption1
Analysis
08.06.2008 39 © Werner Damm , OFFIS
Integration with Autosar: what it takes
PrinciplesAllow association of contracts to SWCsTiming Extensions of Autosar Meta-Model (under development), incl. timing characteristics of BSWSimilarly: Extensions wrt other supported viewpoints, such as safetyAnalysis of System- and ECU configurations to derive promises characterizing configurationTranslation of Autosar Meta-Model concepts into HRC meta-model
VFB, runnables, topology, tasks, …
08.06.2008 40 © Werner Damm , OFFIS
Translation of SW components
Software components of AUTOSAR and those of RCM are similar
Definition as well as refinement can be directlytranslated
AUTOSAR runnables aretransformed into RCM components, Inter Runnable Variables becomeports and connections
AKPS
PDS
AKPS
PDS
<<PortSpec>>PS
discrete in speed : float
HRC
RPort behaviorsee next slides
08.06.2008 41 © Werner Damm , OFFIS
4, March 2008 41 SC - Safety Critical Systems
Triggering runnables – TimerEvents
AUTOSAR runnables are transformed into RCM components, Inter Runnable Variables become portsand connections
Timer events triggering runnables can be mapped to a component which implements the timers behavior
Periods of timer events can be mapped to promisesof timer components
Timer Runnable
Promise:E every10ms
E
08.06.2008 42 © Werner Damm , OFFIS
ConclusionAdding Speeds to Autosar provides a seamless design flow from requirements to Autosar based implementations supportingMulti-viewpoint contract based requirement capturingSemantic integration of industry standard design tools for capturing system-level requirements and specificationsA suite of analysis and design methods, including
Contract compatibility and dominance checkingSystem-level safety and timing analysisDesign Space exploration Hosted Simulation enhanced with run-time contract monitoring
Assessment and optimization of implementation architecture as captured in Autosar configurations