Integrating Simulink Stateflow into a System Development Environment

1
Integrating Simulink / Stateflow into a System
Development Environment

• Frank Altheide, Heiko Dörr, RIC/SM
• frank.altheide heiko.doerr_at_daimlerchrysler.com

2
Typical Application Scenarios
3
Sample Tool Environment forSystem Development
Test case elicitation
RM data base
Hardware in the Loop
Model test
Dynamic modelling
Test of communication
Configuration
Software implementation
Code Generation
SW test
Code checking
4
Application Scenario Modelling Components

• Stepwise construction of model accompanied by
  simultaneous documentation of requirements
• Characteristics
• Model creation within Simulink
• Requirements specification withinRM tool (e.g.
  Doors)
• Assign requirements to model elements
• Trace between requirements and model elements

5
Application Scenario Model Documentation

• Relation REALISESFunction Blocks x Software
  Requirements

6
Tool Integration Goals
7
Tool Integration Goalsw.r.t. Data

• Data integration
• Typical EAI-application transparent access on
  distributed data bases via separate (web-)client
• Realised by 3-layer architecture incorporating
  integrated data model
• Data / model exchange
• Exchange of data with common semantics (e.g. XMI
  for UML models, STEP AP233)
• Assumes common semantics implemented by each of
  the tools
• Data / model transformation
• Simple for data with simple semantics
• High efforts for models with elaborated semantics
  (e.g. statecharts)

8
Tool Integration Goalsw.r.t. Functionality

• Establish fixed work flow connecting the
  functions provided by the tools (e.g. make, Unix
  pipes, stepwise model transformation)
• User driven work flow calling fixed, additional
  data transformation (e.g. MTest)
• Concurrent operation of tools (e.g.
  co-simulation)
• Provide common and additional functionality for
  integrated tools

9
Tool Integration Goalsw.r.t. Presentation

• Application of common widget libraries (e.g.
  Swing, Athena Widgets)
• Common look-and-feel

10
Tool Integration Goals of ToolNet

• Common look-and-feel
• Provide common and additional functionality for
  integrated tools
• Simple data integration
• ... based on tracing information as THE essence
  of integration

11
The ToolNet Approach
12
System Architecture Information Backbone
ToolNetServer
...
Link Manager

• Specific characteristics
• Data remains in tools instead of exchanging it
• Capture common behaviour of tools by specific
  group of services
• Encapsulate functionality relevant for
  integration by Facade pattern
• Concentrate on inter-operation

• Roles of tools within integration
• Project management
• Editor
• Presentation
• Data source
• Link management

...
ToolNet - Backbone
Test Director
ProjectManager
Session Manager
MS Word
13
Detailed System Architecture Interfaces
14
How it looks
15
Conclusion

• ToolNet V1.0 is a framework for the low-cost
  integration of system development tools
• As a sample Simulink / Stateflow has been
  integrated with
• Doors for requirements management and
• CTE for test case elicitation
• At present, pilot applications are executed
• Seeking for co-operation with external partners
• to exploit the framework capabilities
• to extend the set of supported tools and
  integration functionality

16
Backup
17
Characteristics of System Development

• Todays systems are
• Increasingly complex
• Highly reliable
• Essential for differentiation of competition
• Using software as integral part

• Development must be
• Efficient
• Integrate various development disciplines
• Supported by specialised tools
• Problem-oriented

18
User Requirements

• Capability
• Exploit data coincidences
• Perform automatic updates to maintain consistency
• Interchange data
• Support process and work flow
• Intense automation
• Flexibility
• Exchange of tools with similar functionality
• Simple migration to new releases
• Scalable deployment of sub-components

• Extensibility
• Task-oriented
• Tools
• Phases
• Flexible definition of IDEs for system development

19
ToolNet Principles

• Primacy of standard / COTS tools
• Do not substitute functions of primary
  development tools
• Data remain in tools
• Apply standard tools wherever possible
• For development as well as for management tasks
• Scalable development and deployment
• Incremental support of tools and functionality
• Instantiate IDE according to specific needs

• Identical and independent extended API
• Arbitrary combinations of tools can be supported
• Tool and its adapter know best
• Decentralised responsibilities

20
Application Scenario State-based Analysis of
Functionality

• Relation REALISESStates x System Requirements
• State-, function block oriented requirements
  specification
• Each requirement object is realised by state or
  function block

REALISES
21
How to apply ToolNet

22
Application Scenario Distributed Engineering

• Co-operation between several specialists within a
  development project
• Task-oriented development environment based on
  single data sources
• Distributed data must be interconnected
• Data presentation must be consistent and up to
  date

23
Currently supported Tools