1 / 21

Explicit Connectors in Component Based Software Engineering for Distributed Embedded Systems

Explicit Connectors in Component Based Software Engineering for Distributed Embedded Systems. Dietmar Schreiner , Karl M. Göschka Vienna University of Technology Institute of Information Systems Distributed Systems Group 2007. Overview. This talk is about

frances-gonzalez
Télécharger la présentation

Explicit Connectors in Component Based Software Engineering for Distributed Embedded Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Explicit Connectors in Component BasedSoftware Engineering for DistributedEmbedded Systems Dietmar Schreiner, Karl M. Göschka Vienna University of Technology Institute of Information Systems Distributed Systems Group 2007

  2. Overview • This talk is about • Component Based Software Engineering • components • connectors • contracts • Embedded Systems Software • distributed • dependable • resource constrained • Software Development Process • Model Driven Development • Validation and Verification of Composition Models

  3. Contribution • We show • how to simplify the development of component based distributed embedded applications by introducing explicit component connectors within model driven SE (UML 2). • how to support validation of communication properties at model level. • which types of contracts are required for model level validation of communication within composed structures.

  4. Outline • Overview of the Automotive Embedded Systems Domain. • Component Based Software Engineering and Model Driven Development for distributed embedded systems. • Contract Types in Composition Models. • Example Composition with Explicit Connectors and Contracts.

  5. Automotive Embedded SystemsOverview • Today's vehicle networks are truly distributed electronic systems (70+ nodes (=ECUs) [1]). • Cars contain numerous (10+) heterogeneous time or event driven bus systems • CAN, LIN, FlexRay, MOST • x-by-wire • steering aids, ABS, ESP(DSC) • remote window and lock control • engine control • airbag control • navigation systems • entertainment systems [1] P. Hansen. New s-class mercedes: Pioneering electronics. The Hansen Report on Automotive Electronics, 18(8):1–2, October 2005. ‘

  6. Automotive Embedded SystemsTypical Properties • Software is mission critical • highly dependable • hard real-time • typically statically scheduled and bound • Lifetime is rather long (10-14 years) • modular design • exchangeable components (modules) • Systems are produced in high quantities (56.3 million cars in 2005) • costs have to be small • bug fixes are extremely expensive

  7. Outline • Overview of the Automotive Embedded Systems Domain. • Component Based Software Engineering and Model Driven Development for distributed embedded systems. • Contract Types in Composition Models. • Example Composition with Explicit Connectors and Contracts.

  8. Component Based Software EngineeringOverview <contract type=“PI" id="CIFP"> <interface type="API" id="0"> <operation id="exampleService"> <param idx="0" type="void"/> <result type="void"/> <wcet t="0.01s"/> </operation> </interface> </contract> • CBSE is a well known paradigm in classical software engineering. • Applications are built by • assembling components • deploying composed structures within a system environment • Components are considered to be • trusted element of execution • with a well defined usage description • contracts • component contracts • interface contracts • conforming to a component model • interaction standard • composition standard • deployment standard <contract type="RI" id="CIFR"> <interface type="API" id="0"> <operation id="exampleService"> <param idx="0" type="void"/> <result type="void"/> <wcet t="0.05s"/> </operation> </interface> </contract>

  9. Component Based Software EngineeringComponentComposition • Association (connection) of provided and required interfaces • interaction and communication implicit • validation is typically an interface type check, sometimes also a protocol check • Distributed Interaction (Communication) • Fat Components • Light Weight Components + Middleware Adapter

  10. Component Based Software EngineeringCOMPASS[2] Metamodel [1] COMPASS – Component Based Automotive System Software, http://www.infosys.tuwien.ac.at/compass ‘

  11. Component Based Software EngineeringExplicit Connectors • First class architectural entities embodying component interaction • life cycle differs from that of a component • at composition time connectors are abstract representations of interaction properties • connectors “materialize” after the components’ deployment has been specified • connector fragments are component like artefacts • Hide matters of communication and distribution from the application components • simplifies application components • application development no longer requires detailed communication subsystem know-how, when using OTS connector • communication properties are bound to the connectors

  12. Component Based Software EngineeringConnector Fragmentation • Connectors are fragmented if… • components are deployed over process/address space boundaries. • components are deployed over different nodes. • Separation into connector fragments is referred to as deployment anomaly. • Emerging contracts provide more detailed communication properties

  13. Component Based Software EngineeringExplicit Connector Example (RPCA)

  14. Outline • Overview of the Automotive Embedded Systems Domain. • Component Based Software Engineering and Model Driven Development for distributed embedded systems. • Contract Types in Composition Models. • Example Composition with Explicit Connectors and Contracts.

  15. Component Based Software EngineeringContracts • Specify provided and required attributes of associated model elements. • Five main categories: • Component Contract • e.g. memory footprint, ECU restrictions • Interface Contract • e.g. operation signatures, temporal properties of operations • Port Contract • e.g. behavior protocols • Connector Contract • e.g. resource requirements, channel attributes (latency, …) • Platform Contract • e.g. bus timing (in time-driven busses), ECU attributes

  16. Component Based Software EngineeringContracts • Modeled as artifacts associated with related model elements • Simple type hierarchy for contracts allows easy extensions (e.g. interface contracts) • Content of contracts is not predefined. COMPASS contracts are XML documents.

  17. Outline • Overview of the Automotive Embedded Systems Domain. • Component Based Software Engineering and Model Driven Development for distributed embedded systems. • Contract Types in Composition Models. • Example Composition with Explicit Connectors and Contracts.

  18. ExampleComposition • Component Contract • Memory Usage • ECU restrictions • Component Contract • Memory Usage • ECU restrictions <contract type=“PI" id="CIFP"> <interface type="API" id="0"> <operation id="exampleService"> <param idx="0" type="void"/> <result type="void"/> <wcet t="0.01s"/> </operation> </interface> </contract> <contract type="RI" id="CIFR"> <interface type="API" id="0"> <operation id="exampleService"> <param idx="0" type="void"/> <result type="void"/> <wcet t="0.05s"/> </operation> </interface> </contract> • Interface Contract • Interface Type • Operation Signatures • WCET • Interface Contract • Interface Type • Operation Signatures • WCET

  19. ExampleDeployment Specification • Platform Contract • Memory Provision • ECU specification • Platform Contract • Memory Provision • ECU specification Platform Contract <contract type="P" id="CBUS"> <bus id="0"> <buscycle_length t="0.1s"/> <slot_length t="0.02s"/> </bus> </contract>

  20. ExampleConnector Transformation • Calculated Interface Contract • Provides properties of the server component but extends them by the communication subsystem’s constraints. • WCET of operation at server is 0.01s • WCET of connector fragments is 0.01s • BusCycle length = 0.1s (has to be consumed) • provided execution time = 0.12s !! Violation of Contract ! Connector Contract <contract type="C" id="CCFA"> <connector type="RPC"> <response time="1.0 cycle"/> <WCET t="0.01s"/> </connector> </contract>

  21. Conclusion • The introduction of explicit connectors • allows the usage of OTS embedded connectors encapsulating communication logic • eliminates needs for heavy weight middleware • simplifies the development of application components • provides information on required system resources • allows a model level validation of compositional constraints beyond simple type checks • Future Work • Generate custom tailored middleware from application models and connector building blocks. • Develop a more precise meta-model for contracts. Thank You !

More Related