Aerospace Systems Engineer

Behavior Modeling

UML and SysML are a bust for Systems Engineering, but... An Alternative.

Right off the bat I have to vehemently state that the UML and also SysML fails the practicing systems engineer and I do not advocate their use nor the use of any of the UML/SysML based tools: ROSE, Tau, Rhapsody, etc.

There, I said it.  


I do not come to that conclusion lightly.  I have chased this tool set panacea for many years (beginning before UML) and across many assignments and contractors, and with many dedicated engineers trying to make things work for Systems Engineering.  We came up short every time.


As I alluded, I started down this path prior to the coming together of the “three amigos” and the development of the UML. BTW- I always liked Peter Coad's work. At that time we were using every conceivable diagram to try to facilitate requirement and system design derivation and capture.  I have pursued this passion through several different assignments with Lockheed, Boeing, a commercial medical hardware startup and various sub assignments with LM and Boeing.  All of these were “cloistered” environments so sharing artifacts unique to the project and company are of course impossible. 


At almost every assignment, and some I took specifically for this reason, the teams were trying to facilitate Systems Engineering through the use of UML tools.  At Boeing we were using ROSE and I had access to an internal “tool smith” to tweak ROSE.  We had support from Rationale (at the time),  later on that assignment and also with a couple of Lockheed assignments we tried using the Telelogic products; Tau, Rhapsody.  Basically what we, Systems Engineers, need is not supported by the UML.  In conversations with Telelogic discussing what we now call Scenario Sequence Diagrams (SSD) their chief architect acknowledged the utility but stated they would adhere to the UML standard as their business model.  Around that time I wrote an unpublished paper for INCOSE in which we identify the failure of the UML with regard to Systems Engineering.


SysML became the next best hope, and we were following the OMG discussion boards up until the SysML camps fractured and essentially collapsed of its own weight.  Everyone’s pet diagram was included.  Including the SSD, sorta, as the “Activity Diagram with Swim Lanes” - - I say, sorta, because it doesn't fully embrace the intent of the SSD. 


An Alternative - - The SSD
What I have been involved with over the last several years is the development and proselytizing of a methodology and technique for systematically exploring the system behavior problem space.  I first got started this effort when I was with  Scitor working a Ford Aerospace project.  (yes, several years ago)

Our analysis methodology is rooted in solid requirements based Systems Engineering and over the years when we have presented this approach to experienced Systems Engineers we have found they immediately appreciate its utility.  My favorite anecdote is the grizzled Boeing engineer I ran into when asked to present this approach to a contentious sister group “across town”.  He approached me after the room had cleared and I thought he was going to upbraid me for suggesting yet another flash in the pan technique, but instead said, “I haven’t seen such a robust technique since the Apollo program.”  Made my day.


The SSD approach supports the generation, and enhances the utility of, the standard engineering artifacts; specifications, IDD/ICDs and Conops documents.  Various terms have been used for the technique; Scenario analysis, Threads, Sequences, Use Cases, Use Case analysis.  A few years ago we pretty much settled on Use Case elaboration through the use of Scenario Sequence Diagrams.  We use the term Scenario Sequence Diagrams (SSDs) to differentiate from the UML and SysML sequence diagram.


The methodology and the tool integrate Architecture, Behavior and Functions in one construct.  We have used a variety of drawing packages and commercial tools (ROSE and Telelogic discussion above) over the years before (out of frustration) creating a home grown Visio based tool to facilitate the methodology. It ain’t perfect but its way ahead of anything else.  Available on this site.


The methodology starts with the identification of the Systems Use Cases; Install, Initialize, Operate, FD/FI/FR, and Disposal (I am now also advocating adding a development Use Case to cover unique build and test situations).  Each Use Case is elaborated as a Scenario Sequence Diagram, first at the system level (system as actor) then decomposed at specific levels. 


The basics of the diagram;

·       Actors are listed across the top
·       “lifelines” extend down from each actor
·       Processes are shown as “bubbles” on the lifeline
·       Messages between actors are shown as arrows
·       Time flows down the page

ssd

The elements of the diagram capture: Source and derived (and allocated) requirements, architecture (as architectural components and interfaces between components) and behavior both over all conops of the Use Case being elaborated and as required derived behavior to be implemented by the next level of system decomposition.


For the most part I have implemented this approach on assignments as a compendium of analysis packages with individual scenarios assigned to engineers to develop.  On an assignment with Lockheed at Kirtland AFB we used a tailored LM IS&GS Architecture Based Design ABD approach which integrated with this methodology quite successfully.  The approach, as with systems engineering in general, is reliant on understanding the interrelatedness of Requirements, Architecture and Behavior and also the appreciation of the roles of the specification, IDD/ICD and Conops documents in capturing and communicating the system design.


I recommend capturing the scenarios in section 8 of an Operations Concept Document (OCD) following the IEEE/AIAA standard.  Ideally each requirement is linked to the scenario that elaborates it and the parent scenario that allocated it, which can be done in DOORS.  The Visio tool has a robust database which we use in the capture of information embedded in the “smart shapes” but we haven’t yet integrated the database between diagrams nor with a product like DOORS.  Maybe someday? 






The Utility of Scenario Sequence Diagrams (SSDs)

Scenario Sequence Diagrams

The Scenario Sequence Diagrams are multi-purpose diagrams which capture the essential aspects of physical and functional architecture, and system behavior, in one diagram.  These diagrams supplant several of the diagrams commonly used in Systems Engineering design derivation and documentation, and provide utility beyond the combination of all of them.
ssd


Context Diagrams - The Scenario Sequence Diagram, by listing the involved actors across the top of the diagram, illustrates the system’s physical, and functional, context and shows which actors interact in the scenario.


Interface Diagrams - The Scenario Sequence Diagram, through depiction of message traffic graphically, illustrates physical and logical interfaces between actors.


Data Flow Diagram - The Scenario Sequence Diagram data messages illustrates data flow between actors.


Data Dictionary - The Scenario Sequence Diagram, and especially the companion Event Flow Table, through the capture of each specific message provides the equivalent of a data dictionary for the scenario.


Message Sequence Chart- The Scenario Sequence Diagram illustrates sequential message exchanges between actors accomplishing the scenario.


Use Case Model Diagram – The activities populating the vertical “life lines” of the actors are the Use Cases executed by each actor for the scenario.


Activity Diagram - The Scenario Sequence Diagram, through depiction of sequential Use Case execution is analogous, but superior, to the UML “Activity Diagram” in that it identifies the behaviors required of the actor in the execution of the scenario.  The UML “activity diagram” merely shows state without exposing or elaborating behavior.


Event Flow Table

In use, the Scenario Sequence Diagram or SysML Activity Diagram will typically be combined with a textual capture of the system design in an Analysis Package for the scenario.  We use the Event Flow Table as the textual mechanism.  The Event Flow Table provides significant additional aspects which enable the Analysis Package’s utility as a design and requirements validation tool. As CASE tools evolve we can see products such as Telelogic’s TAU integrating the graphic modeling tools with the traditional requirements repositories creating powerful tool sets for the practicing systems engineer and replacing the manual text approach.


Structurally the Event Flow Table is a multi column table capturing the Source, Destination, Message and Activity of each “transaction” in the Scenario Sequence Diagram or SysML Activity Diagram. Because the diagrams represent a sequence the first 2 columns of the EFT can be used to capture the sequential numbering of the transactions in the Scenario and relative times (typically t -0 times) for sequences of transactions. Additionally the Requirements and assumptions columns are used to allocate requirements to design (or derive requirements from functions) and to capture assumptions associated with either.  It is here where the integration of graphic model and requirements repositories are indicated. A comments column is often useful to capture the extraneous bits of information exposed during the analysis of the behavior.  Additional columns are often added for specific attribute capture such as constraints and fault mode identification. 







The Utility of Scenario Sequence Diagrams (SSDs)

Scenario Sequence Diagrams

The Scenario Sequence Diagrams are multi-purpose diagrams which capture the essential aspects of physical and functional architecture, and system behavior, in one diagram.  These diagrams supplant several of the diagrams commonly used in Systems Engineering design derivation and documentation, and provide utility beyond the combination of all of them.
ssd


Context Diagrams - The Scenario Sequence Diagram, by listing the involved actors across the top of the diagram, illustrates the system’s physical, and functional, context and shows which actors interact in the scenario.


Interface Diagrams - The Scenario Sequence Diagram, through depiction of message traffic graphically, illustrates physical and logical interfaces between actors.


Data Flow Diagram - The Scenario Sequence Diagram data messages illustrates data flow between actors.


Data Dictionary - The Scenario Sequence Diagram, and especially the companion Event Flow Table, through the capture of each specific message provides the equivalent of a data dictionary for the scenario.


Message Sequence Chart- The Scenario Sequence Diagram illustrates sequential message exchanges between actors accomplishing the scenario.


Use Case Model Diagram – The activities populating the vertical “life lines” of the actors are the Use Cases executed by each actor for the scenario.


Activity Diagram - The Scenario Sequence Diagram, through depiction of sequential Use Case execution is analogous, but superior, to the UML “Activity Diagram” in that it identifies the behaviors required of the actor in the execution of the scenario.  The UML “activity diagram” merely shows state without exposing or elaborating behavior.


Event Flow Table

In use, the Scenario Sequence Diagram or SysML Activity Diagram will typically be combined with a textual capture of the system design in an Analysis Package for the scenario.  We use the Event Flow Table as the textual mechanism.  The Event Flow Table provides significant additional aspects which enable the Analysis Package’s utility as a design and requirements validation tool. As CASE tools evolve we can see products such as Telelogic’s TAU integrating the graphic modeling tools with the traditional requirements repositories creating powerful tool sets for the practicing systems engineer and replacing the manual text approach.


Structurally the Event Flow Table is a multi column table capturing the Source, Destination, Message and Activity of each “transaction” in the Scenario Sequence Diagram or SysML Activity Diagram. Because the diagrams represent a sequence the first 2 columns of the EFT can be used to capture the sequential numbering of the transactions in the Scenario and relative times (typically t -0 times) for sequences of transactions. Additionally the Requirements and assumptions columns are used to allocate requirements to design (or derive requirements from functions) and to capture assumptions associated with either.  It is here where the integration of graphic model and requirements repositories are indicated. A comments column is often useful to capture the extraneous bits of information exposed during the analysis of the behavior.  Additional columns are often added for specific attribute capture such as constraints and fault mode identification. 







Modeling System Behavior

Probably the biggest problem we face in systems engineering is maintaining continuity of vision throughout the project lifecycle. We have recognized for some time that specifications alone are inadequate.  Initially the problem space is interpreting what it is the customer is really asking for.  Then we move into design iterations, followed by development, test and delivery.

Throughout, even perfectly crafted requirements and specifications are subject to reinterpretation over time and especially when individual requirements are viewed with out context.  Generally it is not the quantitative performance requirements that cause problems but rather the functional or behavior requirements.

The elements of behavior that must be understood include the architectural components and abstractions (both logical and physical), the interactions between components, and the activities of individual components.  All the while recognizing that every system is hierarchical, and every aspect; architectural, interactions and activities decompose downward and abstract upwards.

We have seen a variety of diagrams and techniques come in and out of vogue as systems engineers struggle to perform the basic tasks of systems engineering; Define the problem, Design a solution, Communicate the design, Build the product system, and Test the product system against the design.  Notice I didn’t say; write requirements, create a DOORS database, generate specifications, write a Conops Document, generated FFBD, IDEF0 diagrams, Rose models, etc.  These are artifacts and tools (the means not the end) to achieve the true goal; a product system that fulfills the customer’s needs within the programmatic constraints of budget, time and the reality of physics.  These artifacts and tools only have value when they are used towards the goal and not seen as ends in themselves.  “Begin with the end in mind”
Modeling

Through a single model…
  • we derive the product system requirements?
  • we design the product system?
  • we communicate the product system design?
  • we test the product system?
By recognizing that every system is hierarchical a suite of multiple levels of diagrams depict the system.  An activity of a part of any system is a Use Case or activity of that part of the system. That is a natural decomposition. That “part” owns its Use Case as a requirement to be implemented by the components of that part. Just as the “part” decomposes into components or elemental parts, the behavior (the Use Case/Activity/Requirement) decomposes into elemental behaviors. Behavior and architecture decompose. The typical specification tree captures this as A-Specs, B-Specs, etc. The hierarchal model inherently does the same. The point is not to model individual requirements but to model the system in its entire hierarchical state because the whole is indeed more than the sum of its parts and only in understanding the whole can we avoid the ambiguity of analysis in isolation.

>>>WARNING<<<  Such a hierarchy is exponential, especially when alternate or exception flows are considered.  Triage – not everything is essential to be modeled.  The number one attribute of a systems engineer is common sense.  Focus on risk; essential functionality, new technologies, and interfaces. Model the high risk areas.
Scenario Sequence Diagrams.

Scenario Sequence Diagram, in a single diagram, the capability to model; architectural components and abstractions (both logical and physical), the interactions between components, and the activities of individual components. By focusing on the essential behaviors of every system; Installation, Initialization, Operation, Fault detection, Fault restoration & Maintenance, and Disposal a set of scenarios will define the Level 0 system.  Architecture and interactions are exposed during this exercise thus the first level of decomposition is realized.


ssd


The Scenario Sequence Diagram and SysML Activity Diagram are graphic depictions of a behavior sequence.  The key elements of the SSD are:

       *      Actors – Actors are represented as boxes, except for human actors which are shown as stick figures. The actors of a scenario are shown across the top of the diagram.

       *      Lifelines – Lifelines are the vertical lines drawn down from each actor.  Time proceeds down the page.

       *      Use Case – Use Cases are the behaviors of the actors.  Use Cases are shown as “bubbles” on the lifeline of the actor executing the behavior.

       *      Messages – Messages are sent from a source to a destination actor.  Messages typically trigger an activity of the destination actor.  Messages contain data and/or control directives.

       *      Transaction – A transaction is a sequence of behavior consisting of a message from a source actor to the destination actor, initiating the Use Case of the destination actor.

The SysML Activity Diagram, in the Swim Lane version, provides the same functionality but uses a slightly different vernacular.  Actors are “Parts”, Lifelines are replaced with Swim lanes, Use Case are termed activities, and Messages can be richly represented.







Analysis Package Development Process

This is written for system SEIT level Systems Engineering, but is applicable when tailored (i.e., identify appropriate participants) for use in the segment level SE process also.  The names may vary, the basic functional responsibilities won't.  Every program/project has its own level of necessary ceremony. 

Analysis
1. Assign Use Case to engineer for elaboration and analysis
2. Specify Source (driving) requirement(s) for Use Case (A-Spec)
3. Develop Data Flow Diagram (functional context diagram)
4. Develop Scenario Sequence Diagram (SSD) and associated Event Flow Table
5. Identify source requirements for each transaction (row) of EFT
6. Identify where derived (B-Spec) requirements are needed
7. Identify design assumptions, as required, for each transaction (row) of EFT
8. Include comments/concerns as required, for each transaction (row) of EFT
9. Schedule community review
10. Hold community review
     (Note; this is a non-trivial activity which should be allocated at least I day per use case)
     Participants:
        a. System Architect
         b. Use Case Model Owner
         c. System Model Owner
         d. System SEIT Conops team
         e. System SEIT I&T
        f. System SEll Requirements
        g. Segment representation

11. Make updates to analysis packages as required

12. Perform requirements audit (AP identified Use Case to B-Spec requirement)
13. Generate new derived requirements, as needed
14. Link requirement to AP in DOORS (create an A attribute in DOORS)
15. Prep for SFR
         a. Focus on High Risk requirements (requirements that are vague and have high potential for malicious interpretation with cost/schedule impact)
         b. Make and capture clarifying assumptions for each of above
         c. Insure APs are available in read file

Post SFR System Engineering Design Document (SEDD) development

16. Merge approved/reviewed scenario into System model
17. Support configuration change process, as required, based on review


The Analysis Package


The Analysis Package is a structured engineering artifact that captures architecture and behavior and validates design against requirements.  The typical structure of an Analysis Package is,…






Summary/Overview




Preconditions



Actors:




Context Diagram:




Scenario Sequence Diagram (SSD):




Event Flow Table




Post-Conditions/Notes