1. Eliciting integration scenarios Proposal for Meeting 20130503

2. Terminology To be placed on the “Terminology” wiki page http://open-services.net/wiki/embedded-systems/Terminology/ ES development setup Use Cases Scenarios Priority Topic -An aspect of embedded system development that the ES User Group has identified as of high priority.

3. The ES User Group Top 4 Topics Model-based development -Rainer: Make more specific. MBD testing? Implementation? Etc. Product line engineering -Atego: reuse -Rainer: avoid this topic for the time being, since it overlaps with ALM/PLM workgroup. But we should certainly do later Systems of systems -Rainer: avoid this topic for the time being, since it overlaps with ALM/PLM workgroup. But we should certainly do later Mission critical systems Do we need to define more topics for this User Group?

4. Approach 1.Define a set of typical ES Development “Setup”s 2.For each such setup, define a set of relevant development use cases that highlight some tool interoperability needs. 3.For each use case, define a set of tool interoperability scenarios 4.Identify and generalised scenarios into common patterns To start with  define 1-2 ES setup

5. 1. Define a set of typical ES Development “Setup”s 1 ES Development “Setup” consists of 2 parts: -Part 1 - An embedded system product description That fits to one or more of our top topics Described as: –A simple textual description and/or –A list of functional requirements and/or –A set of models -Part 2 - A tool chain supporting the ES product development Consists of –A set of tools The specific role a tool plays in the tool chain (such as the activities the tool cover) needs to be cleared defined; since a tool can play many different roles. Example, a UML tool can be used as an analysis or design tool in different setups. –A set of development roles/users (development stakeholders) Example: requirements engineering, designer, architect, … –A set of relationships and dependencies between tools Example: data/artefact/model flows between tools An ES Setup ought to cover a small section of the ES development (instead of a big setup for the complete process) An ES Setup should focus on the Top Topics of the ES User Group.

6. Part 1 - An embedded system product description Example: Vehicle cruise control system -(Models below for illustration purposes only) http://www.antony-anderson.com/cruise/3-oper.htm http://www.freepatentsonline.com/6769504.html http://www.wiringdiagrams21.com/2009/07/31/2005-infiniti-qx56-auto-cruise-control-wiring-and-system-circuit-diagram/

7. Part 2 - A tool chain supporting the ES product development (Model below for illustration purposes only) Tool Roles: -Simulink: Models system dynamics Defines control algorithm -UML Software design & coding Tool relationships -Simulink Requ: a trace is defined between control properties in Simulink and corresponding requirements in Requ. Management tool. Requirements Management Matlab/ Simulink UML C compiler Code Generator Simulation Tool Requ. Engineer

8. A typical ES Development “Setup” Brake-by-wire -http://www.timmo-2-use.org/deliverables/TIMMO-2- USE_BBW.pdfhttp://www.timmo-2-use.org/deliverables/TIMMO-2- USE_BBW.pdf Can be used to extract both a product description, and tool chain. Found on web from a simple searching. -Need/can to check Volvo contacts for further details.

9. 2. Define Use Cases 2. For each such setup, define a set of relevant development use cases that highlight some tool interoperability needs. Use 1 UML Use Case diagram -Include development roles/users – as actors -Include a high-level textual description of each use case.

10. 3. Define Scenarios 3. For each use case, define a set of tool interoperability scenarios. Each scenario describes a particular user/tool interaction that includes some kind of tool interoperability need

11. 3. Define Scenarios How to describe a scenario? -Use UML sequence diagrams for each scenario -Scenarios are grouped under corresponding Use Case -Objects consist of either tools or users/developers -Focus is on messages (interactions) between tools (hence integration needs) Messages (interactions) between users can exist for clarification purposes Messages (interactions) between users and tools can exist for clarification purposes -Define preconditions & postconditions for the scenario … Given such a setup, it should be relatively easy to extract “integration specifications“?

12. 4. Identify Patterns 4. Identify and generalised scenarios into common patterns Scenario patterns are submitted to OSLC Workgroups for further consideration