Part 2: Forgetting “ilities”
The second part to our series on “The Forgotten Elements in Systems Engineering” is dedicated to forgetting to involve or just ignoring the “ilities” early in the lifecycle. A simple definition for “ilities” is the developmental, operational, and support requirements a program must address. An even simpler definition is non-functional, requirements. “Ilities” can include scalability, modularity, vulnerability, supportability, etc. Look to the picture on the right to learn more about the different types of “ilities” and the common views. The most common ones systems engineers look at are reliability, attainability, and maintainability or better known as RAM. Much of this conversation will focus on RAM.
You might be wondering “Why RAM is often overlooked until late in the lifecycle?” RAM analysis requires details to estimate uncertainties in estimated values and requirements, which takes time and money. As such, it often is not addressed at all until the detailed design phase. However, RAM should be part of the overall scenario analysis at the very beginning of the concept development phase. For example, you will want to include redundancies to improve reliability and availability. If these trade-offs are done early in the process you may find ways to reduce costs of components during detailed design.
So, why is it so important to include the “ilities” early in the lifecycle? If you do not carefully take into account all the different “ilities” from the beginning of the design phase, then issues will arise later on in the lifecycle. There is a direct relationship between when you find the problem and the more money those problems cost to fix (see picture on the right). Requirements are developed based on the chosen “ilities.” For example, if you have chosen RAM to be your “ilities,” you want to make sure you system is Reliable, Available, and Maintainable. If you are developing a weaponry system for the Army, you need to take into account how many weapons are needed for each location very early in the lifecycle. If you realize that you are short a significant amount of weapons late in the lifecycle, this will affect many of your other requirements. The systems engineers will have to go back to the design phase and look at all the requirements that were affected and this will take a lot of time and money to make sure the weaponry system is available. Losing time and money is a best case scenario if you do not take into account availability. If you find out during the operations and support phase, this could result in a major loss of lives for the Army, if there were not enough weapons readily available. Remembering to carefully analyze the different “ilities” is extremely important for the system’s success.
“Ilities” are directly related to the requirements development process. Below you can see an example of using RAM to write out requirements. It is good writing requirements practice to always use the “ilities” to write out the requirements.
- Reliability: “The spacecraft shall have an on-orbit lifetime of at least five years”
- Availability: “The spacecraft shall have an operational availability of 98%, excluding outages due to weather, with a maximum continuous outage of no more than 72 hours”
- Maintainability: “The spacecraft shall require the removal (or opening) of no more than ten fasteners (panels) to replace any Line Replaceable Unit (LRU) … during pre-launch ground operations”
Where does systems engineering help us remember the “ilities?” Let’s take a look at the Middle Out Process. As you can see from the picture on the right “ilities” should be a part of the lifecycle very early on, starting at Step 4. Capture Constraints. The constraints (or requirements) come from these “ilities.” The Operational Context Diagram needs to take into account “ility” concerns. In Step 11. Define Resources, Error Detection & Recovery, failure modes analysis, an important part of reliability and quality, needs to be included. Finally, Step 13, should include “ility” related scenarios as part of the Operational Demonstration Master Plan.
The Lifeycle Modeling Language (LML) also improves the use of “ilities.” LML includes Asset/Resource entities, Asset Diagrams, and Characteristics/Measures entities, all of which capture physical information about the system. The Action entities, Action Diagrams, and Input/Output capture and model processes, which provide a means to include alternative paths for improving security, RAM, and other “ilities.” Since Action Diagrams include Resources, you can simulate the effect of limited resources, reprovisioning, and other factors related to the “ilities.” Perhaps the most important benefit for modeling “ilities” with the Action Diagram comes from the logical constructs of most languages being replaced by special cases of Action entities, which we call decisions points. This feature enables you to allocate the Action/Decision Points to specific Assets, such as command and control, information assurance, or logistics manager to name a few. Thus the functions performed by the decision makers (hardware, software and wetware) can be captured easily using LML.
The success of the system relies on the systems engineers including reliability, availability, maintainability, supportability, etc. early in the lifecycle. To keep “ilities” in check with the system process follow these three rules: 1) Use the Middle Out Process to remember when to start including the “ilities” in to the lifecycle 2) Take advantage of LML and 3) Increase discussion and interchange among SEs on the topic of “-ilities” and how to best incorporate them into SE.