Aerospace Systems Engineer

2011

The Blog


blog

Steve Nelson
Systems Engineer

A LinkedIn Tools Discussion

I have been chasing a tool to implement the methodology we employ in our system engineering process for many years, since before the three amigos came together.
Early on it was ROOM, then Rose, then TAU. In working with Telelogic (at the time) they said, like your approach and see value in the diagram, but its not UML so we wont support it. There is some material on my blog about this history, but that is neither here nor there.
I was involved in the OMG efforts toward SysML which rapidly became bloated and fractured, but that story is seldom told.
I thought SysML had some promise with the activity diagram with swimlanes. Pictorially it is analogous but the proof is in the metadata.

Your comment that UML/SysML can achieve my goal intrigues me, because I, working with several modeling teams, at a major Aerospace companies, have failed. I will readily admit this could very well be because the "modelers" were often Jr Engineers or, not systems engineers at all, but model builders.

The graphic is important but so is the underlying metadata. The tool should unambiguously link the two.

I am interested in;
Architecture - the actors and their life lines.
And
Behavior - Communication between the actors – messages, and the actions of the actors - Functions.

The UML/SysML activity diagram appears to provide the ability to assign an activity to an actor by its placement in the swimlane. But the model doesn't know or enforce this. The graphic interface doesn’t generate the meta data. Thus we miss a valuable brainstorming aspect.

Also the activity diagram doesn't contain message traffic, thus no triggers for the activity.

When you have a trigger, an actor and an action you have a requirement. "Upon trigger, the actor shall do X". Thus this Use Case behavior analysis as scenarios of behavior fulfills the key SE function of requirement decomposition.

My visio based tool understand the source and destination of a message, and understand the owner of each function. This is provided by the connections to the lifeline. It also understands sequences of the scenario. These are UI generated metadata, not attributes that must be added by the modeler. The tool also provides the opportunity to enter additional data in the message and the functions (actions) and visio captures this in its database. The report function of visio can extract this data and generate a companion table (we call the event flow table) which supports the graphic.

The graphic is much more than a diagram, its the UI, and the metadata.

The touted extensibility of these open systems is typically in areas that really provide little utility, but great opportunity for "modelers" to tinker, and keep Systems Engineers from getting the job done. Happy

The extent of possible diagrams bewilders the junior engineer and they typically think they have to do all of them and with every option. I can't fault the tool for that. Happy

Frankly, and finally, I have heard some good things about Artisan. It was recommended to me by an engineer I respect. I had a trial version, was just before a buyout or name change? A few years ago? I haven't given it a fair assessment. I think there was a foreign ownership issue as well?

At any rate. The slide presentation covers the method and the utility of the diagram in some detail. But only really alludes to the utility of the tool's UI and metadata capture utility.

Feel free to take a more in depth look at the Visio tool.

Nothing would please me more than to find a tool that efficiently supports our needs of brainstorming and robust metadata capture.

ICD Management

ICD management
    The initial step in managing the System’s Interfaces is to identify the System’s architecture. Initially this may be a “notional” architecture which will evolve as the system definition process progresses. Although the system is hierarchically organized it is generally advantageous to identify the architecture to the appropriate level (Depth) to identify meaningful “elements”. Significant elements may be defined by location, discrete functionality or contractual abstraction. Some element are internal to, and a part of, the system some are external.
    Pasted Graphic
    0‑1 – System Context Diagram
      System Interfaces exist to fulfill the needs of the behavior of the system. Use Case elaboration is performed to derive the necessary behavior of the system in fulfilling the essential Use Cases. The systems’s essential Use Cases are typically the key requirements of the system, and typically fall within a structure of “universal” Use Cases: Install, Initialize, Operate (i.e., Mission, Maintenance), Contingency, and Disposal.
      Scenario Sequence Diagrams are both a “brainstorming” tool and a documentation product which identifies and documents the exchanges between system elements (Actors) and also the functions of the actors in the execution of a specific Use Case. The elaboration of a Use Case is performed by a team composed of representatives of the elements of the architecture. As the team “brainstorms” the execution of the Use Case exchanges between actors are defined and the required functions of the Actors are identified. Typical exchanges are data and control/response traffic. The goal is to identify the presence of necessary interfaces.
      Pasted Graphic 1
      0‑1 – Scenario Sequence Diagram
      Identified interfaces may be: Internal, Internal -External or External - External. Internal interfaces are interfaces between elements within the defined system. Internal-External Interfaces are between a system element and an external element. External – External interfaces are interactions external to the system but whose behavior (products of timing) are essential to the achievement of the Use Case.
        Achieving successful functionality requires that both sides of the interface have the same understanding of the interface. Interface Control Documents (ICD) define the interface between two systems. There should be only one interface document between interfacing entities. ICDs define the required behavior and attributes of the interface. These are generally most efficiently captured using the DoD three layer model; Physical, Transport, Application, but the ISO 7 Layer Model is also an alternative.
        ICDs are design documents which must be adhered to, to assure proper behavior of the system. ICDs provide design information to the designers implementing the system functionality. 1.  Where there are no options there is no design latitude and no ambiguity (i.e., the physical envelop of a device) 2.  Where design latitude provides implementation options the ICD documents the design agreements (i.e., device B configured as 1553 RT 5). 3.  Some systems may have utilization options (i.e.. Control directive 123 or control directive ABC will turn on the device. Typically there will be factors to consider in the choice of these control directives. ) 
          Where an established interface exists and is documented by an ICD (or similar document), the engineering effort is typically to assure the interface is understood and allocated appropriately.
          In the case of a new interface the engineering effort may be more extensive.
          Interface characterization is a multi-step process beginning with the identification of the presence of the interface and continuing with the detailing of the attributes of each exchange covered by the ICD. This is part of the design process which may involve a myriad of design considerations and decisions. External interfaces require the participation of cognizant personnel from the external element. It is the ICD’s
          owners responsibility to document the design agreements in the ICD.
            The ICD approval process is tasked with the validation of the correctness of the data in the ICD. Peer Reviews by Subject Matter Expert and Systems Engineering provide the first level of assurance of the correctness of the data. External interfaces typically require Customer and Sponsor participation and often User participation.
            Approval by the relevant approving authority results in placing the approved ICD under configuration control helping to further control the risk associated with interfaces.

              ICDs are invoked from specifications when stipulating exchanges between elements. The practice of specifying an interface between two elements with a global reference to an ICD (i.e., element “Y” shall interface with element “Z” IAW ICD 123) is not useful and should be avoided. To be useful a requirement should invoke the appropriate ICD in the requirement specifying a specific exchange (i.e., Upon detection of “xyz”, element “x” shall provide element “y” time of event IAW ICD “123”.) This provides specificity by identifying a specific exchange rather than all possible exchanges addressed by the ICD. The “receiving” element spec should also have an equivalent requirement specifying its requirement to accept the data. (i.e., Upon receipt of time of event, formatted IAW ICD “123”, element “y” shall process time of event. Where the receiving element is an external actor, it is appropriate to identify “wills” in the appropriate system specification. “Wills” denote expectation of behavior compliance from elements outside the control of the system. Adherence with the will is a contractual obligation of the approving authority upon approval of the specification.
              The practice of “bookending” an exchange in both “sending” and “receiving” specifications helps to insure the system design of each element adheres to the ICD. “bookending” also provides the ability to manage the risk associated with system integration by facilitating verification of ICD compliance prior to the integration of the two elements. “bookending” also facilitates management of ICD compliance by providing a mechanism to audit each ICD attribute against the requirements invoking the interface.

                ICD attributes are validated in an incremental process which insures compliance and mitigates integration risk. The initial efforts were executed during ICD development, Data validation and Approval.
                  An audit of the requirements specifications can be used to provide assurance that the interfacing entities are both referencing the same interface document for the same functions.  Auditing the respective specifications assures that they each reference the appropriate specific section of the correct ICD. This is often what is meant by "verifying" the ICD. It is a method of confirming that the interface is correctly referenced. It is NOT verification in the sense that we verify requirements.
                    Requirement verification of system elements provides an opportunity to verify ICD compliance prior to the integration of elements. Component acceptance testing provides an opportunity to confirm that the expected interface behavior agrees with the documented behavior. This also provides risk reduction prior to assembly.

                    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?