While industry is working out the details of model-based systems engineering implementation, I am going to discuss the most basic concept in systems engineering: The System. The word system creates a difficulty since the word can refer to a system of any degree of complexity, be it an eco-system, an air-traffic control system, a health-care system, a satellite, a ground network, a radar system, or even processing systems and cables.
Taking the time to understand a system (e.g. the system-under-development or the system-of-interest) can be given short shrift in many situations. It just seems too basic an activity to even spend any significant time doing. Get it wrong, though, and you’ll be paying the price for the rest of the system lifetime.
There are two aspects to understanding your system that are important to emphasize.
- Defining the system context
- Defining the system decomposition
Defining the system context
The system context is a well-known aspect of systems engineering. Sometimes represented by a collaboration diagram (SysML) or an OV-1 (UAF), a system context identifies a system’s external interfaces and interfacing systems (or people and organizations). As simple and as straightforward as a system context is, ignore or overlook an external interface and you may be doing re-work instead of system deployment. Here are some considerations offered to help you define your system context and help your implementation of MBSE succeed.
- How many systems do you have? Perhaps identifying your system is difficult because you don’t have a single system, or maybe you are dealing with a collection of legacy systems, or you might have a systems integration project affecting multiple efforts. You may also be dealing with families of systems or systems-of-systems. Whatever the case, you need to think about what the aggregation of your systems looks like.
- Are humans an integral part of your system? If so, you may be dealing with the complexities of a socio-technical system. Humans are part of your system if they are interacting with your system to achieve goals or objectives. If you are an auto manufacturer, humans are users of the system. If you are running a race team, then humans, the driver, and the pit crew are part of the system.
- What is the name of your system? Don’t get confused with the name of the project or company initiative. The system is an entity unto itself and its name calls out its integrity as a system. The name of the system should be unique to avoid confusion. You may have to give your system a new name to help distinguish the system from the management and administration needed to build the system. Also, don’t forget to revisit and reevaluate over the course of the lifecycle. Confusion may arise if the scope of a project has evolved or shifted and old terminology and definitions remain in use.
- What are the external systems? Begin to identify associated systems, or actors, that play a role in supporting or supplying your system. External systems can be defined as systems outside of your management control, objectives or goals—in other words, outside your design boundary. Think both in terms of “nearest neighbor” as well as the ultimate sources and destinations. Common external systems are: Communication Systems, End Users, Stakeholders, Maintenance, and Testing.
- What are the interfaces? Think about the types of interfaces your system may have with external systems and actors. You will certainly think of the data interfaces, but you may also have electrical, thermal, mechanical and verbal interfaces. Resist the impulse to identify these interfaces as the physical implementation, and keep the naming abstract, such as “System/External System interfaces.” These interfaces will later be documented in interface control documents.
- What is the name of the System Context? Having identified and named your system and identified external actors, you have all the necessary pieces for your system context. In some cases, the name of a system is confused with the name of the system context. If this is true for your system, you may need to revisit your naming conventions.
The diagram below depicts a system context for a CubeSat Mission. Note that the CubeSat Mission is modeled as a systems-of-systems. Note also that it interfaces with other external systems such as the Ground Network and Launch Services. The diagram also shows the decomposition of the CubeSat Mission into the CubeSat Satellite and the CubeSat Ground System and depicts interfaces with external systems. I’ll talk more about system decomposition next.
System Context for CubeSat
Defining the system decomposition
After you have defined external systems, people, or organizations, think about the type of system you have. How do you want to refer to your system? Is it an Enterprise? A Systems-of-Systems? Or maybe some component level item. However you view your system, it’s important to name each layer of decomposition.
Consider again the CubeSat model shown previously. A typical system breakdown for a satellite is the following:
System → built from → Subsystems → built from → Components → built from → Parts
On the other hand, if you are dealing with the CubeSat Mission in its entirety, you will want to deal with the CubeSat Ground System in addition to the CubeSat Satellite. Hence, you can name the system of interest a “CubeSat Mission” and consider the CubeSat Mission as a systems-of-systems, in which case the system decomposition would breakdown as follows:
System of Systems → built from → Systems → built from → Subsystems → built from → Assemblies → built from → Parts
Similarly, you could consider the CubeSat Mission as a Family of Systems with the following breakdown:
Family of Systems → built from → Systems → built from → Subsystems → built from → Assemblies → built from → Parts
You might even be responsible for designing a piece of a larger system, but still view it as a system in its own right. Say you are a lens manufacturer for digital single lens cameras. You may view your lens as a system, even though a camera manufacturer might consider the lens a component. In which case, the following breakdown may be more appropriate:
System → built from → Assemblies → built from → Sub-Assemblies → built from → Parts
The following diagram shows a hierarchy of the CubeSat Mission Context with the CubeSat Mission modelled as a Systems of Systems. Note how each layer of the CubeSat Mission is composed of like-typed elements. For example, the CubeSat Operations Console and the Communications Subsystem are all considered “subsystems” in the second level decomposition of the CubeSat Mission.
Hierarchy of the CubeSat Mission Context
There are situations where hardware and software may be included at the same layer of decomposition, so it is important to understand when items of different types occupy similar layers in a system decomposition. The following figure represents such a system decomposition with software represented as CSCI, CSC and CSU.
System Decomposition
Summary
Understanding the context of your system and its piece parts is an essential part of systems engineering. It will help you understand and prepare for all your external interfaces and ensure you develop a well-layered system. Any MBSE project will suffer if these details are not dealt with and updated throughout the architecture and design processes.
To learn how Vitech’s CORE software was used in the design of a cubesat, read our story “Microsatellites in the Age of Space 2.0” on our success stories page.
