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

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

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

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

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

Sequence Diagrams

A Distributed C2BMC Architecture

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

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

UML-RT Models capsules connections ports

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

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.

UML-RT Model for the C2BMC Architecture

Internal structure of the Sensor Fusion Processor

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

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

Architecture of OMNeT++ Simulation

OMNeT++ Simulation Code Structure

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)

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

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

User Interface of the OMNeT++ Simulation

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

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

Backup Slides

Varying Data Rate

Varying Track Message Sizes

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

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

Varying Collaborative Fusion Requests Varying Module Processing Time

Varying Track List Access Time Varying Time to Perform Track Fusion

Varying Master Track List Broadcast Times Varying Data Rate between Capsules