Explicit Connectors in Component Based Software Engineering for

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 – 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 2

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. 3

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. 4

Automotive Embedded Systems Overview • 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, Flex. Ray, 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. ‘ 5

Automotive Embedded Systems Typical 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 6

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. 7

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

Component Based Software Engineering Component Composition • 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 9

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

Component Based Software Engineering Explicit 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 11

Component Based Software Engineering Connector 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 12

Component Based Software Engineering Explicit Connector Example (RPCA) 13

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. 14

Component Based Software Engineering Contracts • 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 15

Component Based Software Engineering Contracts • 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. 16

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. 17

Example Composition Component Contract • Memory Usage • ECU restrictions <contract type=“PI" id="CIFP"> <interface type="API" id="0"> <contract type="RI" id="CIFR"> <operation id="example. Service"> <interface type="API" id="0"> <param idx="0" type="void"/> <operation id="example. Service"> <result type="void"/> <param idx="0" type="void"/> Interface Contract <result type="void"/><wcet t="0. 01 s"/> <wcet t="0. 05 s"/> </operation> • Interface Type </interface> </operation> • Operation Signatures </contract> </interface> • WCET </contract> 18

Example Deployment Specification Platform Contract • Memory Provision • ECU specification <contract type="P" id="CBUS"> <bus id="0"> <buscycle_length t="0. 1 s"/> <slot_length t="0. 02 s"/> </bus> </contract> 19

Example Connector Transformation Calculated Interface Contract Provides properties of the server component but extends them by the Connector Contract communication subsystem’s constraints. <contract type="C" • WCET of operation at server is 0. 01 s id="CCFA"> <connector • WCET of connector fragments type="RPC"> is 0. 01 s <response • Bus. Cycle length = 0. 1 s (has to betime="1. 0 consumed) cycle"/> <WCET t="0. 01 s"/> • </connector> • provided execution time = 0. 12 s !! Violation of Contract ! </contract> 20

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 ! 21