1. J. Michael, M. Shing M. Miklaski, J. Babbitt Naval Postgraduate School
Modeling and Simulation of System-of-Systems Timing Constraints with UML-RT and OMNeT++
J. Michael, M. Shing M. Miklaski, J. Babbitt
Naval Postgraduate School

2. Outline System-of-Systems Challenges
Iterative Use-Case Analysis/ Modeling/Simulation Process
UML-RT Models
OMNeT++ Simulation
Sensor Netting Example
Discussion and Conclusions

3. Challenges in System-of-Systems Development
Must be highly dependable
Complexity makes it difficult to develop
Software-intensive
Distributed, heterogeneous, and network centric
Evolving
System-of-systems that includes legacy systems as well as systems under development
Will operate in an unpredictable environment

4. Meeting Challenges
Need new strategies and methods for developing software - readily transferable to industry
An iterative prototyping process

5. Use Case Analysis of a Ballistic Missile Defense System
Detect Potential Threat Ballistic Missile
Generate and Transmit a Local Track
Cooperatively Track and Classify Threat Ballistic Missiles
Cooperative Weapons Assignment
Engage Targets
Assess Kill

6. Sequence Diagrams

7. A Distributed C2BMC Architecture

8. Boot-strapping the Industrial State-of-Practice
State-of-practice (Stick-and-circle diagrams)
UML-RT Object-Oriented Architectural Models
OMNeT++ simulation

9. UML-RT
A UML profile for describing distributed system architecture (system components, communication relationships, and containment relationships)
Model architectural structure using three constructs
capsules
ports
connectors

10. UML-RT Models
capsules
connections
ports

11. Capsules
Capsules are specialized UML active objects for modeling self-contained components of a system with the following two restrictions:
Capsule operations can only be called within the capsule
Capsules can only communicate with other capsules through special mechanisms called ports

12. Ports
Ports are objects within a capsule that act as interfaces on the boundary of the capsule.
A capsule may have one or more ports through which it is interconnected with other capsules via connectors
Each port is associated with a protocol that captures the semantics of the interactions between the port and its counterpart on the opposite end of the connector
Connectors represent communication channels through which capsules communicate via the sending and receiving of messages.

13. UML-RT Model for the C2BMC Architecture

14. Internal structure of the Sensor Fusion Processor

15. OMNeT++ Simulator An object-oriented modular discrete event simulator
Generate C++ simulation control code
Consists of modules that communicate with message passing
Modules can be nested hierarchically
Simple modules

16. OMNeT++ Model Overview
Models are expressed in terms of a topology description language NED (NEtwork Description)
Module can have parameters to customize module topology, module behavior, and module communication

17. Architecture of OMNeT++ Simulation

18. OMNeT++ Simulation Code Structure

19. OMNeT++ Components Simulation kernel library
Compiler for the NED topology description language (nedc)
Graphical network editor for NED files (GNED)
GUI for simulation execution, links into simulation executable (Tkenv)
Command-line user interface for simulation execution (Cmdenv)

20. OMNeT++ Components (cont’d)
Graphical output vector plotting tool (Plove)
Utilities (random number seed generation tool, makefile creation tool, etc.)
Documentation, sample simulations, contributed material, etc.
Platforms:
Solaris, Linux (or other Unix-like systems) with GNU tools
Win32 and Cygwin32 (Win32 port of gcc)
Win32 and Microsoft Visual C++

21. OMNeT++ Simulation Model for the C2BMC Architecture
Sensor Fusion
Processor

22. User Interface of the OMNeT++ Simulation

23. Simulation Study Goal: Method: Observations:
To determine what were the most significant timing constraints on the system and at what point they became critical
Method:
Vary one input value at a time to see how that one variable impacted the system
data rates, track message sizes, sensor update delay, number of sensors, collaborative fusion requests, module processing time, track list access time, track fusion time, master track list broadcast times
Observations:
Track message size and data throughput rates had little impact on the time to transmit track data
As the track load increased, the Track List capsule would become saturated, thus increasing the time to transmit track data

24. Discussions and Conclusions
The Use Case Analysis/Model-Simulation feedback cycle is useful for refining requirements of complex systems-of-systems
UML-RT provides effective means in capturing complex distributed system architectures
The straight forward mapping between the UML-RT models and the OMNeT++ simulation models provides a seamless process for rapidly constructing executable prototypes for the purpose of analyzing timing constraints and deriving system requirements from those constraints

25. Backup Slides

26. Varying Data Rate

27. Varying Track Message Sizes

28. Varying Ground-based Radar Update Delay
Varying Space-based IR Update Delay

29. Varying Number of Ground-based Radar Sensors
Varying Number of Space-based IR Sensors

30. Varying Collaborative Fusion Requests
Varying Module Processing Time

31. Varying Track List Access Time
Varying Time to Perform Track Fusion

32. Varying Master Track List Broadcast Times
Varying Data Rate between Capsules