Example Patterns from JPL IMCE
Illustrates how a set of Objectives to be achieved may relate to each other.
Illustrates how a set of Missions may be planned to achieve a set of Objectives.
Illustrates how a Mission deploys a set of top-level Components (sometimes called Systems) corresponding to its top-level design and implementation choices.
Illustrates how a Component may be composed of other components. The meaning of contains is context-dependent, but it is always an inverse-functional property. Within a given context, a Component may be contained in at most one Component.
Illustrates how a Component may be an aggregation of other components. The meaning of aggregates is context-dependent, but it is not an inverse-functional property. Within a given context, a Component may be aggregated in more than one Component.
Illustrates how the externally-visible properties of a Component are organized and described.
Illustrates how Interfaces may be joined to connect Components.
Relates Components and Missions to their intended Functions.
Illustrates how Functions are decomposed.
Illustrates the movement of discrete (Item) and non-discrete (Flow) matter or energy across Junctions.
Illustrates the movement of Items and Flow across Interfaces.
Relates a requirement to a formal Constraint on a Property.
Syntactic form of a Requirement specifying compositional structure.
Syntactic form of a Functional Requirement.
Syntactic form of an Interface Requirement.
Illustrates relationships among Requirements at different levels of decomposition hierarchy.
Illustrates effect of Environments on Component.
Illustrates how Components may create Environments (e.g., thermal, RFI, etc.).
A general pattern for ascribing attributes to arbitrary model elements.
A general pattern for explanatory bridges. An Explanation analyzes some model elements and explains others. The interpretation is that the analyzed elements, in the context of the Explanation itself, provide some justification or rationale for the explained elements. The canonical example of Explanation is allocation; a constraint on spacecraft mass can be allocated to a set of constraints on the masses of spacecraft subsystems. The Explanation would provide a rationale for the specific allocations.
Illustrates the relation between Stakeholders and their Concerns. (A mission:Objective is a specialization of project:Concern.)
Illustrates how design and engineering authority is delegated, i.e., the Work Breakdown Structure.
Illustrates the relation between Authorities (e.g., Work Packages) and the Products (e.g., specifications, analyses) they produce.
Illustrates the relation between Authorities (e.g., Work Packages) and the SuppliedElements (e.g., Components) they supply.
Illustrates a general relation between entities as specified by one Authority (e.g., a customer) and as realized by another (e.g., a supplier).
Illustrates the stages of development (e.g., draft, preliminary, final) for an engineered article (e.g., Component, Product, Facility).
Illustrates how Authorities (e.g., WorkPackages) conduct activities in the service of supplying a Mission (and its Components, Products, etc.) A Process is analogous to a Task in critical-path scheduling.
Illustrates execution dependencies among Processes. Analogous to the task-subtask relationship in critical path scheduling.
Illustrates how a Process may interchange specific types of Deliverables.
Illustrates how multiple Processes may cooperate to interchange Deliverables.
Illustrates how Deliverables are interchanged.
Illustrates a Process's directional interchanges of Deliverables.
Systems Engineering is fundamentally a collaborative enterprise. Consequently, it is valuable if not essential to attribute knowledge in an ontological model to an author, or perhaps more precisely, an authority. Assertions do not carry their complete semantics alone; there is always some context required.
Before addressing the specifics of modeling the Work Breakdown Structure, it is worthwhile to review its essential purpose and features; those elements have been somewhat subsumed by incidental considerations in contemporary usage. A well-known reference describes the WBS as follows:
The WBS is a product-oriented family tree that leads to the identification of the functions, activities, tasks, subtasks, work packages, and so on, that must be performed for the completion of a given program. It displays and defines the system (or product) to be developed, produced, operated, and supported, and portrays all of the elements of work to be accomplished. The WBS is not an organizational chart in terms of the project personnel assignments and responsibilities, but does represent and organization of work packages prepared for the purposes of program planning, budgeting, contracting, and reporting.1
Note immediately that the role of the WBS in financial matters (budgeting, reporting) is secondary to its role in planning and organizing the work to be performed. (That's why it's called the Work Breakdown Structure.) In that sense it is fundamental, not incidental, to the practice of systems engineering. It does, of course, play a role in financial matters, but that is primarily because the most rational way to plan budgets and accrue costs is to align the accounting structure with the actual structural decomposition of the work to be performed. Financial structures follow work structures, not the other way around.
A simple endeavor that can be successfully accomplished by one person or a small cooperating team does not necessarily require a WBS, and it almost certainly does not require a hierarchical WBS with multiple levels. More complex enterprises, however, are characterized by the need to divide the work up in ways that can be delegated to teams, each team having considerable discretion in the execution of its tasks, including the further subdivision of those tasks into subtasks and their assignment to subteams. This leads to the familiar tree-structured WBS. We say each node in this tree is an Authority, meaning that it represents the power to author (that is, to create). The edges in the tree represent delegation of authority; a higher-level Authority assigns some subset of its authoring power to a lower-level Authority.
There are, of course, other powers: the power to require, to review, to ratify, to reject, to direct, etc. Each of these can be seen, however, as an exercise of authoring power: to state a requirement, to write a review, to issue a statement of ratification, to issue a policy directive, etc. While it may seem a bit artificial at first, construing authority as the power to create gives us a simple organizing principle for models that allows for a natural association between authorities (programs, projects, work packages) and the things they produce (designs, reports, hardware, software, science data, etc.).
For the purposes of reflecting long-standing practices at NASA and JPL, we further refine the notion of Authority into Program, Project, and Work Package with the restriction that nothing may delegate to a Program and only a Program may delegate to a Project.
Consider this notion of authority in the context of modeling: a model is a set of assertions (whether textual, graphical, or otherwise). These assertions are created (or authored) by humans or by automated agents acting as their proxies. In that sense they are the result of exercise of authority. In exactly the same way that a large engineering enterprise becomes tractable through the hierarchical delegation of authority, a large model becomes manageable through an isomorphic delegation of modeling authority. It is worth reiterating at this point that, if the WBS is the organizing principle of the work, then it must also be the organizing principle of the model, because model-building is part of the work.
We can state some invariants for effecting authority delegation in large complex models:
- Every assertion in the model is asserted by a single authority.
- For every assertion in the model it is possible to determine explicitly and unambiguously which authority asserted it.
- For every authority in the model it is possible to determine explicitly and unambiguously which assertions it has made.
In the field of knowledge management the association of assertions with asserting authority is sometimes called provenance. It should become clear upon reflection that provenance must be expressed by some means other than ordinary model assertions. Otherwise, the provenance assertions are themselves subject to provenance assertions, leading to paradoxical self-reference. Similar issues arise in other disciplines. For example, the Semantic Web's Resource Description Framework exploits a concept called named graphs to convey provenance.2 Named graphs associate a graph identifier with an RDF statement (assertion) in such a way that the invariants above are preserved. Specifically,
- Every RDF statement belongs to a single graph.
- The RDF query language SPARQL permits retrieving the graph associated with each of a set of statements satisfying a query pattern.
- The same mechanism permits restricting a query to a specific graph or set of graphs.
We turn to the problem of conveying authorization (or provenance) in UML/SysML. (For the purpose of discussion we well refer to the SysML profile and its antecedents as "SysML".) SysML includes a Package construct that matches fairly closely the semantics required to maintain our authorization invariants.3 In particular:
- Every model element belongs to a single package.
- For every model element it is possible to determine which package it belongs to.
- For every package it is possible to determine the model elements that belong to it.
Consequently, it is natural to use the packaging capability of SysML to convey authority. The following subsections elaborate on this idea to illustrate a general approach to authority-based model organization.
Authority-based SysML model organization can be summarized in the form of a few principles:
- Every authority (project, program, work package) is represented in the model as a UML Package. Packages representing authorities have applied stereotypes from the IMCE Project Ontology: «project:Project», «project:Program», or «project:WorkPackage».
- All model assertions made by a given authority are contained in that authority's package or in a (possibly transitively-) contained non-authority package thereof. That is, every assertion is authorized by its innermost containing authority.
- Authorization of another authority is interpreted as delegation. (Note: There may be practical reasons for allowing some greater flexibility in conveying authorization via package containment. For such cases the «project:authorizes» relationship may use convey delegation from one authority to another. We interpret occurrences of «project:authorizes» as superseding any delegation implied by package containment.)
When a large enterprise creates a Work Breakdown Structure to convey authority delegation, it is nearly always true that the authorities (work packages) in that structure have customer/supplier relationships with each other. Consider the following WBS fragment:
1 Project
1.1 Flight System
1.1.1 Propulsion Subsystem
1.1.2 Telecom Subsystem
etc.
1.2 Ground System
etc.
In common usage, the numbering and indentation convey that
- 1 Project is the customer for Flight System and Ground System.
- 1.1 Flight System is the supplier of the Flight System.
- 1.1 Flight System is the customer for Propulsion Subsystem and Telecom Subsystem
- 1.1.1 Propulsion Subsystem is the supplier of the Propulsion Subsystem.
- 1.1.2 Telecom Subsystem is the supplier of the Telecom Subsystem.
- 1.2 Ground System is the supplier of the Ground System.
In general, the customer's position (demand) is asserted first, and the supplier responds to that demand. We will consider each in turn. (Note that we do not assume a formal procurement at every customer/supplier interface. The principles and modeling patterns apply wherever there is delegation of authority and exchange of value.)
The general mechanism for asserting demand is simply to assert existence of the demanded object. For example, if the Europa Clipper Project (an authority) wishes to assert a demand for a Flight System, it merely creates a stereotyped «mission:Component» in its package or any sub-package for which Flight System is the innermost containing authority.
In general, it is not sufficient for an authority merely to declare it is the customer for a demanded object; the demand itself will not cause the object to appear. The general pattern is that the customer authority further authorizes a supplying authority and explicitly relates the supplier and the thing supplied:
Note that by the Fundamental Principles above, we can interpret this diagram as saying that the Europa Clipper Project authorizes the following declarations:
- There shall be a «mission:Component» named Flight System.
- There shall be a «project:WorkPackage» named Flight System.
- The Flight System Work Package supplies the Flight System Component.
Taken together, these statements denote a delegation of authority. That is, the Europa Clipper Project delegates the authority to design and build the Flight System to the Flight System Work Package. The Project, of course, retains its authority to levy requirements and acceptance criteria on the Flight System as appropriate to its role as customer.
Having been delegated the authority to supply a Flight System, the Flight System Work Package responds by producing a design specification that describes an actual Flight System that complies with the constraints embodied in the Project's specifications. The model element representing this Flight System is contained within the Flight System Work Package; all properties, characterizations, or other assertions made about the Flight System within this package represent the exercise of the Flight System Work Package's design authority.
A Work Package may supply more than one component. Consequently, we use the «project:realizes» relationship to indicate that a particular component purports to be a satisfactory realization of a particular customer specification. The process of ensuring that it does is called verification, and other model elements will be necessary to convey its activities and results. Although the diagram does not convey it, the «project:realizes» relationship is asserted by the supplier (i.e., the Flight System Work Package), because the claim it conveys is made by the supplier. Claims about verification may be made by both customer and supplier.
To emphasize what may not be obvious, the two «mission:Component»s in the above diagram, although they have the same name stem ("Flight System"). Their qualified names, of course, are distinct because they appear at different locations in the containment tree. While this may seem confusing, two factors mitigate against considering it a serious problem:
- the name stems are not required to be identical and can be specialized as required, and
- most of the engineering work performed by either authority is local to it and will involve only one such component.
- Benjamin S. Blanchard and Wolter J. Fabrycky, Systems Engineering and Analysis, Prentice-Hall, Inc., 1981.
- Jeremy J. Carroll, Christian Bizer, Pat Hayes, Patrick Stickler, Named Graphs, Provenance, and Trust, Proceedings of the 14th International Conference on World Wide Web, 2005.
- Object Management Group, OMG Meta Object Facility (MOF) Core Specification, Version 2.4.2, 2014.