In my blog post last month, Understanding Your System, I discussed the importance of the system context and system decomposition when defining the physical design of a system. This month I would like to additionally emphasize the role of functional analysis to define the functional design and explain how MBSE can be used to unify both the functional and the physical designs of a system.
Functional analysis is the part of systems engineering that studies the intended behavior of the system of interest and results in a functional design, sometimes referred to as a functional architecture or functional model. Functional analysis is conducted incrementally in conjunction with system decomposition and the development of a physical design. Together, the functional and physical designs provide sufficient argumentation to define a system.
Model-based systems engineering (MBSE) provides new methodologies for systems engineering. While MBSE can be confused with functional analysis, or modeling and simulation, it is actually the systems metamodel supporting MBSE that provides a means to unify functional and physical designs. I’ll first discuss some pointers for performing functional analysis and then explain how a rich systems metamodel can help tie the design together.
Defining the Functional Design
Functional analysis is a well-known and sometimes overlooked step in the systems engineering process. The functional design resulting from functional analysis is documented with an activity diagram (from SysML), an SV-3 or SV-10 (from UAF), or a Functional Flow Block Diagram (FFBD). There are many methods for performing functional analysis. Depending on the systems development lifecycle, you may employ use cases or user stories. Here are some considerations offered to help you define your system functional design.
- Consider the System Perspective.
Functional Analysis should be conducted from the perspective of the system of interest. While closely associated with operational analysis, which focuses on behavior and process involved with the operation of a system, functional analysis focuses on the intended system behavior necessary to support a concept of operations.
- Look for the verbs.
Functions are best expressed with verb constructions. Any system domain will come with a set of verbs that describe how a system behaves. Be on the lookout for these verbs. Avoid generic verbs such as “provide” or “perform” when possible. The more descriptive the verb the deeper the understanding you will have of your system.
- Start system decomposition with the functions.
Model what you want your system to do rather than how you want it implemented. The sub-functions of your system will point you toward the eventual sub-systems in your physical design. Likewise, sub-functions of your subsystems will point you to the eventual assemblies in your physical design. You can start either with functional hierarchies (see Figure 1) or behavior diagrams (see Figure 2), but both are informative.
- Understand the behavior.
Think about behavior simply in terms of serial and parallel activities. This will help you focus on the essential details. If you find there are some natural groupings of functions, consider adding another layer to your system decomposition.
- Think about the functional exchanges.
Too often data exchanges are depicted between physical elements of a system, but the depiction of exchanges of data and other items is more properly included in the functional design of the system. Figure 2 shows an example of CubeSat telemetry exchanged between the function Collect Science Data and the function Command and Control CubeSat, rather than between the CubeSat satellite and the ground system, for example. It is better to show the physical interfaces in the physical design—but that’s a topic for a future posting.
A Systems Metamodel for MBSE
There will come a day when it will be important to demonstrate to stakeholders how the functional design matches with the physical design. MBSE can be most effectively applied to this task with a rich systems metamodel that describes these relationships in detail. A metamodel can be expressed as an entity-relationship model and forms the basis of a schema for a relational database. A reduced systems metamodel for functional analysis and system design including physical components, functions, and data items is shown in Figure 3.
As depicted in Figure 3, functions (behavioral entities) may be related to components (physical or virtual entities) using an “allocated to” relationship, while components may be related to functions using a “performs” relationship. Functions are “decomposed” by other functions (and also “decomposed by” other functions), and components are “built from” other components (and “built in” other components). Lastly, items (exchange entities) may be exchanged between functions using “input to” and “output from” relationships.
When your MBSE tooling is based on such a systems metamodel, the results are a powerful means to track these key aspects of a system design. For example, Figure 4 shows the relationship “built from” in detail.
Another example shown in Figure 5, CubeSat Telemetry (a data item) is “output from” Collect Science Data and “input to” Command and Control CubeSat.
Another example shown in Figure 5, CubeSat Telemetry (a data item) is “output from” Collect Science Data and “input to” Command and Control CubeSat.
Summary
Functional analysis, and the resulting functional design, is usually developed layer by layer in the system decomposition and precedes the formation of a physical design at any given layer. A good functional model uses descriptive verb-noun constructions that help downstream development and requirements identification.
A rich systems metamodel can assist with associating information in database management systems and help to organize increasingly complex system information in ways that will assist queries and automated generation of system documentation. While you focus on MBSE, modeling, and simulation, don’t forget about the role of functional design when identifying the behavior and data exchanges of a system, and how it can tie to the physical design.