Component models for embedded systems: from UML to Autosar François Terrier with contributions from Sylvain Robert, Ansgar Radermacher, Frédéric Loiret CEA-List francois.terrier@cea.fr DTSI Monterey Workshop, Paris - 2006, October 17 1
Local context of researchs @ Usine Logicielle DTSI Monterey Workshop, Paris - 2006, October 17 2
Design and control of complex systems
Multi domain tools for Model Driven Engineering @ � Heterogeneity & interoperability management Usine Logicielle Heterogeneous modeling Verification, Formalisms Scade Scilab testing, MARTE Formalisms Bridges UML RTE DSL Plug DSL Plug Bridges Models co-simulation UML2 Model Action EMF Meta transfortation Component Language Reposit. M language Container Execution infrastructure built through generation & libraries Integration of fault tolerance services www.usine-logicielle.org Design and control of complex systems
� Research program on embedded systems AUTOMOTIVE AUTOMOTIVE for automotive & transportation NUM@TEC NUM@TEC AUTOMOTIVE AUTOMOTIVE Requirement Heterogenous modeling, system traceability simulation & ADL Execution Performance platform and analysis design for on OSEK Safety plateform Automotive instanciation @ Usine Logicielle Design and control of complex systems www.numatec-automotive.com
UML & Component model … Starting with a UML profile for RT! DTSI Monterey Workshop, Paris - 2006, October 17 6
Building a MDE tool chain for RTES a conceptual framework � a development process and method, � a set to software engineering tools � an execution platform � � to assist in developing applications from requirements to deployment System System Spec. Prototyper • UML and profile based approach valider Analyst Analyst � UML models Accord|UML � Modelling rules Prototyping rules • UML 2.0 Profiles Prototype � For RTE concepts Model PAM DAM Req. • Tools to support methodology documents Validation � Automated refinement Model � Pattern appliance Accord|UML Accord|UML Accord|UML Testing Preliminary Detailed analysis � Model validation Validation rules analysis rules rules Model • Dedicated RT Kernel Accord|UML Testing rules � Code generation DTSI Monterey Workshop, Paris - 2006, October 17 7
Introduce High level concepts � RealTimeObject: extend UML active object aRealTimeObject Selection & UML stereotype concurrency control Memory space ope_1 signal_1 task Method ... Attributes code � Chose way to model RealTimeObject behavior � Use of protocol state machines ( � now in UML2, see DIPES’2000…) & Algorithmic Algorithmic Logic Logic initReg[cptVit->getSpeed()=<30] Class behavior-Control logic (protocol of use) /display("ON"); maintainSp() initReg() On Off tm(100)/tgSpeed = cptVit->getSpeed(); Off On stopReg() C stopReg/display("OFF"); /delta=k1*atan(tgSpeed-cuSpeed); mot->sendCmd(coupleVariation); [carSpeed=<30]/display("OFF"); start_ maintainSp() Regulator Begin Regulator +tgSpeed : integer carSpeed = cptVit->getSpeed(); Method behavior +initReg() delta=k1*atan(tgSpeed-cuSpeed); tgSpeed : Algorithmic parts +stopReg() mot->sendCmd(coupleVariation); int initReg() +maintainSp() End stopReg() / endOf_maintainSp() DTSI Monterey Workshop, Paris - 2006, October 17 8
Fix execution model � Specify queue management policy Refine UML protocol � Specify signal management statemachines � Specify concurrency constraints � … � Attach selection criteria on each message in the queue � RealTimeFeature � Declare constraints instead to implement them for implementation/platform independence purpose… DTSI Monterey Workshop, Paris - 2006, October 17 9
Building complete models � Separate control (object life cycle) from data processing: Control mechanisms are modeled using state machines � Data processing actions are modeled using UML activity diagrams � • Require addition of explicit notations and some basic actions Mathematical actions are modeled using MathML language syntax � • Accord |AL proposes two formalisms A textual (edited in the model) � A graphic based on UML activity diagram � Java like Ada like SDL like …. � In the profile, each action is defined by 3 elements + examples: semantics, textual notation (in EBNF), graphic notation DTSI Monterey Workshop, Paris - 2006, October 17 10
Modeling rules for preliminary model definition � Interactions with the developed system seen as a black box Focuss on use case definition and collaboration specifications DTSI Monterey Workshop, Paris - 2006, October 17 11
Assistance and automation: generation (& trace) of the detailed model squeleton DTSI Monterey Workshop, Paris - 2006, October 17 12
Model translation into formal model Behavior analysis through symbolic execution Formal analysis of system behavior from its UML model DTSI Monterey Workshop, Paris - 2006, October 17 13
Feedback for behaviour representation Test sequences automatically generated and imported in modeler DTSI Monterey Workshop, Paris - 2006, October 17 14
UML for RTES: a set of ongoing actions Formalise an action language Executable UML foundation Time model (clock/synchr) MOF Characteristics Ressources UML 2 Aligment of timing XMI infos Autosar 2 DTSI Monterey Workshop, Paris - 2006, October 17 15
Overview of the tool set EMF Reposit. Method support UML2 UML back bone MetaM Formal techniques Accord 1 prof Req. prof Requirement MARTE Action validation Lang. Ed. Sched. prof Platform Accord n prof models Scheduling analysis Test. prof Comp. ADL prof. Test Code, generation wrapper generator Component Based Execution infrastructure built through generation & libraries DTSI Monterey Workshop, Paris - 2006, October 17 16
Component diagram � Model the system architecture identifying • Modular and replaceable parts of a system � Content is encapsulated � Can be replaced during design time or execution time • Provided and required interface describing: � Some structural points (attributes, associations, …) � Its behaviour (operation, reception, state-machine, …) • Two possible views � Extern (“black box”): contract of use, visible behaviour � Intern (“white box”) � Shows elements being purely intern to the component (« private ») � Shows how behaviour defined by the interface are implemented • Connexion mechanisms � Interface dependencies (association, use, realization) DTSI Monterey Workshop, Paris - 2006, October 17 17
UML 2.0 Interface � Specify operation, signal, attribute, behaviour � No instances (~abstract class) � “Provided” � realized by a classifier (Class, Component…) A classifier can realize several interfaces � Required � used by a classifier Provided Provided provided « Interface » « component » operation Starter SpeedRegulator start() Starter Display stop() provided Figure2: condensed notation « reception » signal OnOff reaction maxSp: float provided data DTSI Monterey Workshop, Paris - 2006, October 17 18
Interface can have constraint of use • Conformance between Interface / Realisation � protocol state-machine conformance State invariant, pre- and post-conditions of interface � protocol apply on realization state-machine TorqueManager +start() OnOff {protocol} +stop() � New states, -calcTorque() transitions, « reception » waiting operations, start +OnOff stop receptions running +maxSp: float are allowed OnOff -targetSp: float calcTorque « Interface » {protocol} � Possible formal interpretation: OnOff Starter - Real. state Inv. ⇒ Interf. state Inv. start() waiting - For each mapped operation stop() start « reception » stop � Interf. Pre ⇒ Real. Pre OnOff running � Real. Post ⇒ Interf. Post maxSp: float OnOff DTSI Monterey Workshop, Paris - 2006, October 17 19
Connectors • Delegation connector links interfaces of a component with contained parts « component » SpeedRegulator � Used to model behaviour implementation in nested TorqueManager Starter Display components mySSM 0..1 SpM_I � Implementation conformity required « component » SpeedSensorManager DispSp • Assembly connector links required and provided interfaces Implicit assembly connector « component » « component » RegulatorScreen SpeedRegulator Starter Display � Conformity of the interfaces required DTSI Monterey Workshop, Paris - 2006, October 17 20
Ports • Ports to structure usages of the interfaces « component » SpeedRegulator TorqueManager Starter Display ErrorIn mySSM 0..1 SpM_I « component » ErrorOut SpeedSensorManager DispSp • Ports making explicit communication links {CCM RPC} « component » « component » SpeedRegulator RegulatorScreen DTSI Monterey Workshop, Paris - 2006, October 17 21
• From Models to Implementation: � Use of a MW component model DTSI Monterey Workshop, Paris - 2006, October 17 22
A CCM component and its container • Principle of CCM component definition Life cycle management CIDL component Receptacles deployment Facets CCM descr. IDL Event Component interface sink Event descr. source Mgt component Attributes • CCM component model DTSI Monterey Workshop, Paris - 2006, October 17 23
Recommend
More recommend
