The systems we develop interface to external entities. The systems interact, impact, and are impacted by the environment and environmental factors. The systems we develop do not exist in isolation.
The environment and environmental factors play a significant role in shaping the design our system. This article discusses how these elements can be captured in our system model. If done incorrectly, we either trivialize their representation or conversely over-complicate our model.
System Interactions with The Environment
The system requirements may specify how the system should cope and tolerate environmental factors such as wind and rain. When we determine the system’s context we identify the external actors our system will interact with. Therefore, it is appropriate to include the environmental elements in the system’s context.
Kossiakoff and Sweet identify the interactions the system has with environmental elements as falling into two types: primary or secondary. Primary interactions involve the environmental elements interacting with the system’s primary functions. For example, a primary interaction may be our system measuring the temperature of the environment. Secondary interactions are identified as nonfunctional interactions. For example, the system has to operate in a range of temperatures.
In addition, as discussed by Blanchard and Fabrycky, techniques such as Design for Disposability and Design for Sustainability require us to understand the relationships between our system, and the processes for building our system, on the environment.
Representing System Interactions with The Environment
Vitech’s STRATA™ Methodology and System Definition Language allow us to represent the environmental factors we are concerned about in appropriate ways.
Representation of Environmental Primary and Secondary Interactions
Secondary interactions can be represented as constraint Requirements which specify a Component in our system design. For example, if we have a requirement regarding the siting of a system near water, such as:
“On land, the service equipment shall be located no closer than 1.5 m (5 ft) horizontally from the shoreline and live parts evaluated a minimum of 300 mm (12 in.) above the electrical datum plane.”
We can represent this as constraining our system.
When the system has a primary environmental interaction, for example, when the system needs to measure the height of the water,
“Service equipment shall disconnect when the water level reaches the height of the established electrical datum plane.”
We can represent the requirement as the basis of a function in our system. We can represent the environmental element as a Component of type Environment in our System Context.
We can include an Interface between the environmental element and our system to represent the water height being measured. Because height of the water is a continuous signal it could be represented as an Item (Data Store) which is an Input into a Function in the behavior model.
Other examples of a primary environmental interaction include a system that needs to measure lightning versus a system that needs to be protected against lightning damage. In the case of measuring lightning, as lightning occurs as a discrete event it may be appropriate to represent the measurement of the lightning strike as an Item (Trigger) which is a Trigger into Functions in the behavior model.
Representation of Design for Disposability and Sustainability
Leveraging the ability of CORE and GENESYS to represent the consumption and production of Resources in a system behavior model or an operational behavior model, we can include the disposability and sustainability of environmental factors in our model. For example, using Resources we can represent the consumption and production of recycled material in our system construction and retirement.
Conclusions
As you undertake your system design, consider how it will interact with the environment and identify those interactions appropriately. You will then be able to represent them in your CORE™ or GENESYS™ system model with sufficient detail and not introduce unnecessary complexity.
Bibliography
Kossiakoff, A, Sweet, W.N., Systems Engineering Principles and Practice, Wiley, 2003
Blanchard, B.S., Fabrycky, W.J., Systems Engineering and Analysis, Prentice Hall, 2011
NPFA 70: National Electrical Code 2005, NPFA, 2004
