Bridging the gap between requirements engineering and systems architecting: the Elephant Specification Language

Abstract

This article presents a domain-specific language for writing highly structured multilevel system specifications. The language effectively bridges the gap between requirements engineering and systems architecting by enabling the direct derivation of a dependency graph from the system specifications. The dependency graph allows for the easy manipulation, visualization and analysis of the system architecture, ensuring the consistency among written system specifications and visual system architecture models. The system architecture models provide direct feedback on the completeness of the system specifications. The language and associated tooling has been made publicly available and has been applied in several industrial case studies. In this article, the fundamental concepts and way of working of the language are explained using an illustrative example.

1. Introduction

Pahl & Beitz (2007) define engineering design as ‘the process of creating and optimizing solutions in the form of technical systems for problems within the design space spanned by needs, requirements and constraints that are set by material, technological, economic, legal, environmental and human-related considerations’. The needs, requirements and constraints are usually specified in text documents written in natural language, and are often referred to as system specifications (Hull, Jackson & Dick 2017). Design engineers have to interpret these system specifications and convert them into technical designs. A recent development is the transition of document-driven systems engineering toward model-based systems engineering (Madni & Sievers 2018; De Saqui-Sannes et al. 2022; Campo et al. 2023; Wilking et al. 2024).

An important step in the conversion of needs, requirements and constraints into technical solutions is the design of the system’s architecture (Eggert 2005). First of all, the system’s architecture has a significant impact on the system’s performance, for example, reliability, availability, maintainability and cost of the system (Jiao, Simpson & Siddique 2007; Lough, Stone & Tumer 2009). Second, insight into the system’s architecture is required for effective change management (Giffin et al. 2009). That is, requirements often change during the design process, which may cause redesign of one or more components. Such design changes may propagate through the system yielding redesign of other components (Jarratt et al. 2011). A model of the system architecture can be used to evaluate the impact of design changes (Clarkson, Simons & Eckert 2004).

It is common practice to relate needs, requirements and constraints to technical aspects of the system (Pahl & Beitz 2007; Hull et al. 2017). Therefore, engineers need methods to structure, visualize and analyze the relations between system architecture, needs, requirements and constraints. In many existing methods and tools, systems engineers and systems architects have to manually ensure the consistency among systems specifications and various system architecture models. This results in a rather heavy coordination effort. Transitioning from document-driven systems engineering toward model-based systems engineering methods may provide opportunities to bridge the present gap between requirements engineering and system architecting. Automated document derivation from a system model is presented in the review by Wilking et al. (2024) as one of the use case categories in MBSE.

Ulrich (1995) defines system architecture as the mapping of a system’s functions to the components within the system, and to the dependencies between those components. In our previous work (Wilschut et al. 2018b), we have shown that the intended system architecture can be derived from structured function specifications. In this article, a fixed grammar is used to describe goal and transformation functions, referred to as exogenous and endogenous functions by Crilly (2013). We showed that by specifying both types of functions using a structured textual format, one can automatically derive dependencies between components, between functions, between parameters, as well as derive the mapping of functions onto components, parameters onto functions and parameters onto components, and visualize those dependencies. The components used within the function specifications may represent functional components without a notion of solution principle and physical components with a distinct embodiment.

This presents an effective method to generate a dependency structure matrix (DSM) model (Steward 1981) of the system architecture. Eppinger & Browning (2012) refer to the DSM as the ‘system architecture matrix’, defining system architecture as the structure of a system embodied in its elements and their relationships giving rise to its functions and behaviors.

In Wilschut et al. (2018b), however, we have limited ourselves to a single level description of the system. The functions are specified at a single granularity level. Design processes are usually hierarchical in nature (Estefan 2007). Different parts of a system are usually described at different levels of granularity in system specifications (Maier, Eckert & Clarkson 2017). As the design process progresses, the level of granularity of system specifications may become finer. That is, as more details of the system become apparent, the grain size at which a system is described becomes smaller (Eppinger et al. 2014).

Furthermore, in Wilschut et al. (2018b), we only consider functions of the components of the system. Nonfunctional aspects, for example, geometry of components, are not described. Therefore, only intended component dependencies that result from intended functionality are derived. Unintended dependencies between components, for example, a spatial dependency between two components that have to fit in a predefined space, are not derived. Knowledge of intended as well as unintended dependencies between system components is essential in engineering design.

In this article, we develop a novel specification language that enables the structured specification of a system’s functions, behavior and design in terms of needs, requirements and constraints at various levels of granularity. The language is named the Elephant Specification Language (ESL). A parser and compiler have been developed that check the consistency of ESL specifications and derive dependencies between components, variables, needs, goal specifications, transformation specifications, design specifications, behavior specifications, relations and combinations thereof across all decomposition levels of the specification, following a predefined set of mathematical rules.

Contrary to the popular SysML notation, which extends UML with requirements diagrams (De Saqui-Sannes et al. 2022), ESL relies on a dedicated syntax to specify the functional requirements and a mathematical network representation to derive the dependencies between the elements in the requirement specifications. This enables the automated generation of system architecting models from the ESL requirements specifications. To achieve such functionality in SySML would require the rigorous and strict use of specification conventions, which is very difficult to achieve in practice.

This article presents the design of the domain specific language with the various language elements, and the principle rules to derive the various dependencies. For the design of the language, we draw upon the design science literature regarding functional modeling and design structure modeling.

The outline of this article is as follows. Section 2 briefly describes the research method that has been adopted for the research and development of the new language. Section 3 elaborates on the typical elements of a system specification and how these elements are modeled. Additionally, existing methods and tools for the creation of system specifications are briefly discussed. In Section 4, the line of reasoning underpinning the ESL structure, ESL language elements and automated dependency derivations is presented. In Section 5, a small three-level ESL example is presented to illustrate parts of the syntax of ESL and show the derived system architecture models at various levels of granularity. Section 6 describes how ESL can be used during the whole engineering design process. The article is concluded with Section 7.

2. Research method

The presented method and language have been developed following the spiral of applied research as presented by Eckert, Stacey & Clarkson (2003). Method and language development started as part of a 4-year PhD project funded by Rijkswaterstaat (RWS), the executive branch of the Dutch Ministry of Infrastructure. RWS frequently conducts European public tenders procedures for the design and realization of a variety of civil works such as bridges, navigation locks, tunnels and roads.

Systems specifications used within these tender procedures have been reviewed to get an overview of the structure and content of these natural language systems specifications used in real-life projects. Herein, we limited the scope of ‘system’ to the object that had to be designed, realized and integrated in the environment.

Simultaneously, the literature has been consulted for methods on tools on writing system specifications, modeling architectures and the relation between them. The most import works from the literature are summarized in the following section.

The system specification and literature review were the basis for defining the language primitives and grammar, building upon the work presented in Wilschut et al. (2018b).

The language syntax and semantics have been developed over the course of 2 years during which many variations to describe parts of real-life system specifications and to automatically derive system architectures have been tested. This converged into a stable set of language primitives, language syntax and semantics, and architecture derivations rules.

In the following years, the language has been tested and improved in various industry domains, such as infrastructure (Wilschut et al. 2018a), high-tech (Meeusen et al. 2019; Kools 2022), maritime (Herremans et al. 2022) and fusion engineering and related big-science projects (Beernaert et al. 2024a , b ), as part of various Master and PhD projects, and industry design projects.

3. Related work

Writing ‘high-quality’ system specifications is essential to the success of a design project (Buede 2009). Inconsistencies and ambiguities in system specifications may cause costly and lengthy design iterations. Much has been written on structuring and managing system specifications by academia and industry alike (see, e.g., Hooks 1994; Grady 2014; Hull et al. 2017). In this section, we elaborate on what elements are typically described in system specifications.

3.1. Writing system specifications

In the literature, one finds many design process models such as the waterfall model (Royce 1987), the spiral-model (Boehm 1988), the V-model (Forsberg & Mooz 1991) and the onion model (Childers & Long 1994). All these models have in common that one starts with a high-level description of a system, its functions and variables. Subsequently, one decomposes the system, its functions and variables until one obtains a specification (design) that is sufficiently detailed for manufacturing purposes.

Many scientists advocate the usage of separate decomposition trees for the system’s components, functions and variables (see, e.g., Suh 1998; Dym & Brown 2012; Pahl & Beitz 2007) and the subsequent manual mapping of components to functions and variables. Crilly (2013) shows, however, that obtaining such a mapping is far from trivial. That is, components may have multiple functions and functions may be fulfilled by multiple components and involve multiple variables. For that reason, Crilly (2013) introduced new function terminology. Crilly (2013) introduced the terms exogenous and endogenous functions. These terms are similar in meaning to the terms goal function and transformation function of Eisenbart, Blessing & Gericke (2012), which are used by Wilschut et al. (2018b). Exogenous functions describe the purpose of a component with respect to the components around it, while endogenous functions describe processes internal to the component.

The article by Crilly (2013) shows that functions may propagate through nested systems. That is, a function may state that a power source provides power to a lamp. If one subsequently decomposes the power source into a battery and a holder, one may find out that it is actually the battery that provides power to the lamp. This means, the function ‘provide power to the lamp’ is not decomposed into subfunctions but simply assigned to a subcomponent of the power source.

A design project starts with capturing the Voice-of-the-Customer in a series of statements usually referred to as needs (Eppinger & Ulrich 2015). Needs describe what is wanted by the customer. Needs are typically qualitative, imprecise and ambiguous due to their linguistic origins (Jiao & Chen 2006).

In literature, the term ‘requirement’ is often used interchangeably with the term ‘need’, though several scholars define requirements to be structured and formalized needs (Ericson et al. 2009; Cascini, Fantoni & Montagna 2013). This is in line with the work of Jiao & Chen (2006) in which they describe an engineering design process of gathering customer needs and subsequent elicitation, analysis and specification of formalized requirements. What is more, the term ‘constraint’ is often used interchangeably with the term ‘requirement’ (Glinz 2007). In the Oxford dictionary (Oxford 2009), a requirement is defined as a thing demanded, whereas a constraint is defined as a limitation or restriction. These definitions are consistent with definitions by Koelsch (2016). Constraints may, for instance, be imposed by the laws of nature, material properties and the environment in which the system is ought to function.

In this study, we consider needs to be informal (qualitative) statements on what is desired; requirements to be formal (quantitative) statements on what is desired and constraints to be formal statements that impose limits on what is desired.

Hull et al. (2017) point out the benefits of using consistent language in specifying needs, requirements and constraints. These benefits have been recognized by many authors. For example, Cohen (1990) defined linguistic equivalents for mathematical inequality operators, Hooks (1994) debate the usage of the word ‘shall’ in requirements and van Vliet (2005) introduced the MoSCoW method (Must-o-Should-Could-o-Won’t) to create subtle priority differences in requirements, for example, to distinguish between requirements and preferences. Furthermore, several engineers advocate the usage of boilerplates, that is, a fixed layout in which requirements must be written (see, e.g., Arora et al. 2014; Mahmud, Seceleanu & Ljungkrantz 2017).

In the literature, one can find a wide variety of terminology stating different types of needs, requirements and constraints, in the following referred to as requirement and constraint specifications, or specifications for short, for example, stakeholder, system, function, behavior, structure, performance, quality and safety specifications (Koelsch 2016). This motivated the increasing popularity of ontology-driven requirement engineering (Chen et al. 2013; Dermeval et al. 2015), in which prior to writing a specification, one defines the classes of requirements that may occur within a specification.

In general, specifications define the desired system functions, system design (structure), system behavior and derivative properties thereof such as cost, weight and reliability (Fernandes & Machado 2016; Koelsch 2016). A similar classification of requirements is made in the NASA Systems Engineering handbook (Hirshorn, Voss & Bromley 2017): functional requirements are functions needed to accomplish the objectives, while performance requirements define how well the system needs to perform the functions. The INCOSE systems engineering handbook (INCOSE 2023) distinguishes functional/performance requirements, fitness for use requirements (e.g., safety, security and -ilities), design requirements (that constrain the solution) and environment requirements (e.g., operational, maintenance and transportation). As such, any specification method and tool should support the specification of the aforementioned elements.

In the literature, a variety of definitions for function, design and behavior specifications are found. Eisenbart et al. (2012), for example, reviewed 12 different definitions of system functions and partitioned them into two groups. The first group are functions that describe a goal of a system. The second group are functions that describe a transformation of flow, such as electrical energy or information. Following this rationale, in Wilschut et al. (2018b), we defined a specific grammar for function specifications in both groups to reduce ambiguity, that is, a specific sentence structure for writing goal functions to describe the goal of components with respect to other components in the system and a specific sentence structure for writing transformation functions to describe transformations of flow within components. To reduce ambiguity even further, we made use of the functional basis, developed by Stone & Wood (2000) and Hirtz et al. (2002)), to restrict the usage of verb synonyms.

System behavior is often modeled in conjunction with system functions and system states. See, for example, the Function–Behavior–State model (Umeda et al. 1996), the Structure–Behavior–Function model (Goel, Rugaber & Vattam 2009; Komoto & Tomiyama 2012) and the requirements engineering book of Hull (Hull et al. 2017). These models all have their own definitions of behavior, function and state. In general, however, behavior seems to be defined as everything what a ‘thing’ shall or can do in response to stimuli, that is, when which flows need to be transferred and transformed in what quantity in response to stimuli. Stimuli are changes in (un)controllable flows (state changes). In practice, behavior specifications are usually of the form: when a certain condition holds, then certain behavior shall (not) be exhibited.

The literature has less consensus on design specifications which are referred to by a variety of terms such as performance, quality and safety specifications (Koelsch 2016). We interpret design specifications as descriptions of the conceptual, embodiment and detailed design of a system or derivative properties thereof such as capacity, reliability, availability and cost of components. The conceptual, embodiment and detailed design denote different stages of maturity of a design (Pahl & Beitz 2007).

Hull et al. (2017) note that function and design specifications are often combined in single sentences. For example, the sentence ‘The power source must provide power with a reliability of 98%’ contains the subclause ‘with a reliability of 98%’ that is subordinate to the main clause ‘The power source must provide power’. In this case, the main clause describes the function, whereas the subclause describes a performance bound on the function.

In this study, we adopt the specification rationale of Crilly (2013) and Wilschut et al. (2018b). By doing so, we aim to avoid the difficulties of connecting separate component, function and variable decomposition trees and aim to enable functions to propagate through the system decomposition tree.

3.2. Dependencies

In engineering design, systems are usually decomposed into more manageable components (Pahl & Beitz (2007)). It is important to specify and actively manage dependencies between components to ensure that the components eventually will fit and function together (Eppinger et al. 2014). That is, it is important to keep track of and obtain a complete overview of the system’s structure and architecture.

Component dependencies may relate to a wide variety of engineering disciplines such as mechanical, electrical, thermal and software engineering (Tilstra, Seepersad & Wood 2012), making it impossible for a single person to oversee all dependencies (Sosa, Eppinger & Rowles 2007). Therefore, dependencies between components are often visualized and analyzed using graphical models. A major challenge in this process is to ensure and maintain the consistency between the written specifications and the graphical models as the design process progresses. This motivated the development of graphical specification methods such as SysML (Friedenthal, Moore & Steiner 2014).

Written documents, however, remain the primary means of documentation and communication in engineering design (Tomiyama et al. 2013). This may be due to the limited scalability of graphical specification methods (Tosserams et al. 2010). As a consequence, in practice, requirements engineering and system architecting are often performed as relatively independent tasks. However, they are clearly highly interdependent as the specifications influence the architecture and vice versa. Therefore, we consider a direct relation between the written specification and the graphical models as a desirable feature in engineering design.

3.3. Methods and tools

As discussed in the beginning of this section, we argue that a system specification method or tool should enable a user to specify function specifications, behavior specifications, design specifications and combinations thereof in terms of needs, requirements and constraints. Moreover, we consider it desirable to have a direct relation between written specifications and graphical models to display dependencies between components, functions, variables and combinations thereof. In other words, one should be able to directly derive the structure and architecture of a system from the specifications. Finally, one should be able to easily detail the granularity level of the specification as the design process progresses and enable functions to propagate through the nested systems.

In the literature, a variety of requirement management tools are found (see De Gea et al. 2012 for an extensive overview and classification). As the name suggests, these tools mainly focus on the management of large volumes of requirements; they do not consider the conciseness and preciseness of the written specifications themselves. As a consequence, specifications may still be vague and ambiguous. What is more, in most available tooling, users have to manually create the links between components, functions and variables (and many other types of artifacts that one can create within these tools). This results in a significant administrative workload for system engineers and architects. Typically, no direct relation between the written specification and the dependency structure exists. Hence, the resulting dependencies networks are error prone and difficult to verify, validate and maintain.

To improve the preciseness and conciseness of the written specifications, several authors advocate the use of boilerplates (see, e.g., Arora et al. 2014; Hull et al. 2017; Mahmud et al. 2017). Boilerplates predefine a fixed format in which the specifications should be written; however, they do not constrain the actual content of the specifications. Ghosh et al. (2016) and Mustafa, Kadir & Ibrahim (2017) develop tooling to automatically convert natural language specifications such that they are formatted following a set of predefined boilerplates. Manual checking is needed to verify the correctness of these conversions.

Other researchers aim at improving the quality of manually written specifications using controlled natural languages. Kuhn (2014) provides an overview of more than 100 controlled natural languages. Most controlled natural languages are used to simplify and automate the translation of user and service manuals in a variety of languages. Only a few focus on system specifications.

Clark et al. (2005), for example, developed a controlled natural language for writing knowledge databases for artificial intelligence systems. They noticed that many engineers have difficulties with writing the logical expressions in mathematical form which are stored in such a database. They developed a language that enables engineers to write natural language rules and automatically convert them into logical expressions. Fuchs, Kaljurand & Kuhn (2008) developed Attempto Constrained English (ACE) as a natural language specification tool. ACE supports automatic conversion to first-order logic. To the best of our knowledge, ACE does not support the structured multilevel description of systems. Mavin et al. (2009) developed the Easy Approach to Requirements Syntax, which, as we understand them, are automated boilerplates. That is, the tool identifies keywords such as ‘shall’, ‘if’, ‘where’ and ‘while’, but the text between those keywords is not constrained to a predefined format. Feiler, Delange & Wrage (2016) developed the language ReqSpec, which resembles a programming language and is specifically built for the construction industry to perform spatial analysis and design of buildings. Therefore, ReqSpec does not support the concept of system functions. Similar to ReqSpec, the Ψ-language (Tosserams et al. 2010) and the z-language (Woodcock & Davies 1996) are domain-specific languages. The former is used for specifying the structure of multidisciplinary optimization problems, and the latter is used for formally describing computing systems.

De Saqui-Sannes et al. (2022) categorize languages, tools and methods for MBSE and propose selection criteria in their recent review paper. They distinguish three categories of languages: nonformal, semiformal (often diagrammatic) and languages with a formal semantics enabling mathematical proofs. They list examples of well-known generic semiformal languages such as Matlab Simulink, Modelica and the Object-Proces-Methology (Dori, Reinhartz-Berger & Sturm 2003). Two informal MBSE domain-specific languages are outlined, being SysML and Arcadia/Capella. Formal languages have a clearly defined syntax and a formalized semantics. The semantics of a formal language builds upon a mathematical paradigm. De Saqui-Sannes et al. (2022) distinguish state-transition models (such as timed automata and petri nets) and process algebra and logics. Software tools accompanying such informal and formal languages offer model-checking, simulation, verification, code-generation and test generation capabilities. Finally, De Saqui-Sannes et al. (2022) note that the languages and tools should be accompanied with an associated method or standard of use.

4. The Elephant Specification Language

Given the state of the art in system specification methods and tools, we postulate that systems engineers and architects would benefit from a domain-specific language that supports the following features:

1. 1. the specification of function specifications, design specifications, behavior specifications and combinations thereof in terms of needs, requirements and constraints of new and existing systems at multiple levels of granularity;

2. 2. the automated derivation of dependencies between components, function specifications, design specifications, behavior specifications and combinations thereof from the specification themselves;

3. 3. the automated propagation of functions through nested systems.

The ESL is specifically designed to support all three features. Moreover, ESL has been designed from an engineering perspective rather than an information management perspective. It has been designed to blend requirements engineering and system architecting by allowing one to automatically generate systems architecture models from the requirement specifications. Perhaps counterintuitively, ESL therefore deliberately deviates from a few classical systems engineering concepts, such as the usage of separate product, function and requirement breakdown structures and the separate modeling of system architectures at functional, conceptual, technological and physical abstraction levels.

Instead, ESL is built upon a system-centered specification perspective. The decomposition of the system into subsystems and components (product breakdown structure) is taken as the central decomposition tree. Components are viewed as black boxes with inputs and outputs (Erden et al. 2008). This may seem to be in contradiction to scholars who advocate ‘solution-free’ modeling, such as Pahl & Beitz (2007) and Stone & Wood (2000), who often advocate a function- or process-centered specification perspective. However, components in ESL may represent conceptual ‘blobs’, functional units or physical components. A such, in ESL, a component function specification can be solution-free or with a particular solution in mind. As a result, the decomposition tree may contain a mix of these solution-free and solution-specific (physical embodiment) descriptions of components. The component specifications will change, and the decomposition tree will grow (more decomposition levels) as the design process evolves over time.

Moreover, in practice, 100%-new-to-the-world design rarely happens. Engineers typically try to leverage existing designs and solutions as much as possible to reduce costs, lead times and development risks. As such, some parts of a system might already be fully designed and tested in the field, while others are still in the conceptual design phase. Moreover, Caldwell et al. (2012) showed that abstract function models are often difficult to understand withouth the context of the (physical) composition of the system at hand. Hence, we adopted a system-centered specification perspective.

Finally, contrary to popular graphical modeling languages such as SySML, ESL is fully text-based. We intentionally chose a text-based format to allow for easy version management using conventional version control methods and tools, such as GIT and SVN, which have been used in software development for decades.

In the remainder of this section, we introduce in an informal way a selection of key ESL elements. For a full overview of the language and the accompanying tools, one is refered to the ESL user manual (Ratio Innovations B.V. 2020c), the ESL reference manual (Ratio Innovations B.V. 2020b) and the ESL language enhancement proposals (Ratio Innovations B.V. 2020a).

4.1. Components

Many engineers experience difficulties in defining and mapping system, function and variable decompositions to each other (Crilly 2013). Therefore, ESL only allows for the definition of a single decomposition: a system decomposition tree (product breakdown structure) consisting of components. The components represent parts of the system. Such a part may represent a conceptual ‘blob’ (a part we wish not to give a particular name yet) or an off-the-shelf component.

Each component must have a definition and must be instantiated as a subcomponent within a (higher-level) parent component. ESL has the built-in world component, which is the root of the decomposition tree. The world is not part of the system but represents the environment in which the system operates. The component tree (system decomposition) forms the central structure of an ESL specification. All ESL statements are placed within the component tree. For example, Listing 1 shows a world containing a single component pump-module-pm which is a PumpModule.

Listing 1: Decomposing a component

1 world

2    component

3       pump-module-pm is a PumpModule

4

5 define component PumpModule

6    components

7       motor-mt is an ElectricMotor

8       pump-pm is a Pump

9

10 define component ElectricMotor

11       empty

12

13 define component Pump

14       empty

Component pump-module-pm has two subcomponents, being motor-mt and pump-pm, which are instantiated within the definition of PumpModule. Component motor-mt is an ElectricMotor and pump-pm is a Pump, both of which are empty. That is, they have no subcomponents (yet). One could, however, define and instantiate subcomponents within the definitions ElectricMotor and the Pump to add additional layers to the system decomposition. The definition and instantiation mechanism allows one to create a system decomposition with an arbitrary number of branches each of which has an arbitrary number of levels. Moreover, it allows for the easy reuse of component definitions.

4.2. Variables and types

In engineering design, it is common practice to describe a design in terms of variables. ESL enables the user to declare variables within components. The variables may represent flows from the interaction basis (Tilstra et al. 2012), such as electrical energy and information, or properties (attributes) of components, such as length, weight, cost and reliability.

Each variable must have a type, which needs to be defined by the user. The type of a variable provides additional information about the nature of that variable. For example, whether the variable represents a solid or a liquid material flow and what unit it has. The variable types enable consistency checks as variables are passed along multiple levels of the system decomposition tree. ESL supports the mechanism of actual and formal parameters to pass variables across levels of the decomposition tree, which is common in programming languages.

4.3. Verbs and prepositions

The many synonyms of verbs in natural language may cause ambiguity in system specifications (Deng 2002). Therefore, ESL enforces users to define all verb–preposition combinations that are allowed in ESL function specifications. It is advised to use verbs from the functional basis of Hirtz et al. (2002), which all have a distinct definition.

4.4. Needs

Needs are informal statements on what is desired (Jiao & Chen 2006). A need specification within ESL has to start with a reference to an instantiated component or a reference to a declared variable. The component or the variable is the subject of the need. All words that follow the subject are unconstrained, that is, a user may write pure natural language. A need may, for instance, describe desired functionality or that a component shall be compliant with a certain standard or norm, as shown in Listing 2. A need can also be used to express political, social and economic factors that are hard to quantify but need to be considered during design of the system.

Listing 2: Example need specification

1 need

2       n-cm-01: control-module-cm shall be IP68 compliant

4.5. Function specifications

The goal- and transformation-function sentence structures by Wilschut et al. (2018b) fit well within the system-centered modeling perspective of ESL as goal and transformation functions are formulated in terms of components and variables. The concepts of goal and transformation functions, as presented by Wilschut et al. (2018b), are therefore woven into ESL.

Goal-function specifications denote the purpose of components with respect to other components within the system. Goal-function specifications can be extended with one or more subclauses that state additional design specifications that are subordinate to the main clause.

Listing 3 shows, for example, goal requirement g-mt-01 that states that component motor-mt shall provide torque-kp to component pump-pm, such that nominal-torque-kn is equal to 100 [N/m].

Listing 3: Example goal-requirement specification

1 goal-requirement

2       g-mt-01: motor-mt shall provide torque-kp to pump-pm with subclause

3       * s1: nominal-torque-kn shall be equal to 100 [N/m]

Transformation specifications describe the internal conversion processes within a component. Listing 4 shows example transformation requirement t-pm-01 that states that an instantiation of definition Pump internally shall convert torque-kp into water-flow-qs.

Listing 4: Example transformation requirement

1 define component Pump

2    parameters

3       torque-kp is a MechanicalEnergyFlow

4       water-flow-qs is a LiquidMaterialFlow

5

6    transformation-requirement

7       t-pm-01: shall convert torque-kp into water-flow-qs

4.6. Design specifications

Design specifications denote bounds on the values of variables. These variables might represent flows that are used within goal and transformation specifications or properties of components.

Listing 5 shows example design specification dr-st-01 that states that storage-capacity-v shall be at least $ 0.5\;{\mathrm{m}}^3 $ . The variable storage-capacity-st is a property of component storage-tank-st, which implies that storage-capacity-v directly relates to the design of component storage-tank-st. Note that one could make multiple instances of component definition StorageTank. Therefore, design specification dr-st-01 is not written within component definition StorageTank. Otherwise, all instances of StorageTank shall have a storage capacity of at least at least $ 0.5\;{\mathrm{m}}^3 $ .

Listing 5: Example design-requirement specification

1 world

2    variable

3       storage-capacity-v is a Volume

4

5 component

6    storage-tank-st is a StorageThank with arguments

7       * storage-capacity-v

8

9 design-requirement

10    dr-st-01: storage-capacity-v shall be at least 0.5 [m^3]

11

12

13 define component StorageTank

14    parameter

15       storage-capacity-v is a Volume property

4.7. Behavior specifications

Static functionality can be described using goal and transformation specifications. Behavior specifications can be used to describe requirements regarding dynamic behavior. That is, behavior specifications can be used to describe when a system should do what. These statements are static. ESL does not simulate these statements.

Listing 6 shows example behavior requirement b-motor-torque that defines three cases. Case motor-on defines that torque-kp shall be at least 100 Nm when control-signal-ce is equal to True, that is, the motor shall be on. Case motor-on defines that torque-kp shall be equal 0 Nm when control-signal-ce is equal to False, that is, the motor shall be off. Case fallback defines that when no other case applies, that is, for none of the cases the when clauses evaluate to true, then torque-kp shall be equal 0 Nm, that is, the motor shall be off.

Listing 6: Example behavior-requirement specification

1 behavior-requirement

2    b-motor-torque:

3       case motor-on:

4          when

5             * c1: control-signal-ce is equal to True [-]

6          then

7             * r1: torque-kp shall be at least 100 [Nm]

8 case motor-off:

9      when

10       * c1: control-signal-ce is equal to False [−]

11    then

12       * r1: torque-kp shall be equal to 0 [Nm]

13    case fallback:

14       when no other case applies

15       then

16          * r1: torque-kp shall be equal to 0 [Nm]

4.8. Relations

The variables in the design of a system may depend on each other in a variety of ways. For example, the second law of Newton dictates a dependency between force, mass and acceleration; and the weight of a component equals to sum of the weight of its subcomponents. Similarly, the reliability of a component depends on the reliability of its subcomponents.

ESL, therefore, supports the specification of the existence of dependencies between variables by means of relations. The specification of the actual equations that mathematically describe those dependencies is beyond the scope of ESL as there exist many (domain-specific) programming and modeling languages for this purpose. The network of dependencies, however, can be used to automatically construct a multidisciplinary design optimization problem (Beernaert & Etman 2019).

4.9. Comments and tags

System specifications are often annotated with comments. ESL has two kinds of comments: code comments and annotation comments. Code comments are not part of the specification but are used to write down information that is relevant to the engineers who are creating and reading the specification. Annotation comments are part of the system specification and are attached as documentation to components, variables, needs, goal specifications, transformation specifications, design specifications and relations. That is, annotation comments can be used to specify additional arbitrary textual information that is not captured by the ESL elements themselves.

In addition, one can attach special tags to components, variables, needs, goal specifications, transformation specifications, design specifications and relatios using annotations comments. Tagging allows one to categorize annotations comments, for example, to tag a component or specification with the responsible stakeholder(s) or to indicate that status of a specification (e.g., draft or final). As such, comments and tags can be used to enrich ESL specifications.

Listing 7 shows the various forms of comments. Code comments are indicated using #, while annotation comments are indicated using # $ < $ . By using @ within an annotation comment, one can attach tags to ESL elements.

Listing 7: ESL code and annotations comments

1 world

2       # Code comment.

3       variable

4          x is a real #< In line annotation comment.

5

6 comment

7       x #< Annotation comment block for longer text.

8       #< @TagName Tagged annotation comment.

5. Illustrative example

Since the appearance of the first version of ESL in 2018, it has been applied to create system specifications in a variety of industries such as infrastructure (Wilschut et al. 2018a), fusion engineering and big science (Beernaert et al. 2022 , 2024a , b ), the maritime industry (Herremans et al. 2022) and high tech (Meeusen et al. 2019; Kools 2022).

This article focusses on the concepts and way-of-working of ESL, rather than on the application of ESL in an industrial setting. Hence, the usage of ESL is illustrated using an extended three-level version of the water storage system example used in our preceding paper (Wilschut et al. (2018b)) to explain the concepts of goal and transformation functions.

Figure 1 shows the four-level hierarchy of the water storage system specification. The world is the root of the specifications and contains two components: water-storage-system-sts and water-source-ws. Component water-storage-system-sts is the system of interest and is composed of power-supply-ps, pump-module-pm, control-module-cm and storage-tank-st. In turn, pump-module-pm is composed of motor-mt and pump-pm. Component control-module-cm is composed of controller-ct and sensor-sp.

Figure 1. The four-level hierarchy defined within the water storage system specification. The world is the root of the specification, and the water-strorage-system-sts is the system of interest.

5.1. System specification

The ESL specification of the water storage system is shown in Listing 8 through Listing 12. An ESL specification may be written in a single file or distributed over multiple files.

Typically, a preamble.esl file is created that contains all type, verb and relation definitions. Listing 8 shows the preamble.esl file of the water storage system example in which nine variable types and eight verb–preposition combinations are defined. Note that in the combination accumulate yielding, the word yielding is not a preposition but a second finite verb.

Next, a world.esl file is created that contains the world definition of the ESL specification. Listing 9 shows the world definition of the water storage example specification.

Listing 8: Type and verb definitions

1 define type

2       MechanicalEnergyFlow is a real with unit Nm

3       LiquidMaterialFlow is a real with unit l/s

4       ElectricalEnergyFlow is a real with unit W

5       ElectricalPotential is a real with unit Wh

6       Volume is a real with unit m^3

7       ControlSignal is a boolean

8         StatusSignal is a boolean

9         DataSignal is a real

10       Pressure is a real with unit Bar

11

12    define verb

13       provide to

14       provide for

15       measure within

16       send to

17       convert into

18       pump from

19       accumulate yielding

20       distribute over

Listing 9: World definition

1 world

2    variables

3       water-source-flow-qs is a LiquidMaterialFlow

4

5    components

6       water-source-ws is a WaterSource with arguments

7          * water-source-flow-qs

8

9       water-storage-system-sts is a WaterStorageSystem with arguments

10        * water-source-flow-qs

11

12    goal-requirement

13       g-sts-01: water-storage-system-sts shall pump water-source-flow-qs from water-source-ws

Within the world definition, the components water-source-ws and water-storage-system are instantiated. Goal requirement g-sts-01 states that the purpose of water-storage-system-sts is to pump water-source-flow-qs from water-source-ws. In general, the interactions of the system-of-interest with other systems (components) that exist within its environment are defined within the world. In this case, that interaction is quantified by variable water-source-flow-qs, which is defined to be a LiquidMaterialFlow with unit l/s and is passed along as an argument to both components.

In practice, it is often convenient to create separate files for each component definition to allow for easy reuse. Here, the definitions of WaterSource and WaterStorageSystem are listed in Listing 10. An instance of WaterSource shall internally provide water-source-volume-vs as a source for water-source-flow-qs.

Listing 10: Water storage system level-1 component definitions

1 define component WaterSource

2    parameter

3       water-source-flow-qs is a LiquidMaterialFlow

4

5    variable

6       water-source-volume-vs is a Volume

7

8    transformation-requirement

9       t-ws-01: shall provide water-source-volume-vs for water-source-flow-qs

10

11

12 define component WaterStorageSystem

13    parameter

14       water-source-flow-qs is a LiquidMaterialFlow

15

16 variables

17    pressure-wp is a Pressure

18    control-signal-ce is a ControlSignal

19    power-pe, power-pc is an ElectricalEnergyFlow

20    water-volume-vs, storage-capacity-v is a Volume

21    internal-water-flow-qi is a LiquidMaterialFlow

22

23    transformation-requirement

24       t-sts-01: shall accumulate water-source-flow-qs yielding water-volume-vs

25

26    components

27       power-supply-ps is a Battery with arguments

28          * power-pe

29          * power-pc

30

31       pump-module-pm is a PumpModule with arguments

32          * water-source-flow-qs

33          * internal-water-flow-qi

34          * control-signal-ce

35          * power-pe

36

37       control-module-cm is a ControlModule with arguments

38          * power-pc

39          * control-signal-ce

40          * pressure-wp

41

42       storage-tank-st is a StorageTank with arguments

43          * internal-water-flow-qi

44          * storage-capacity-v

45          * pressure-wp

46          * water-volume-vs

47

48    need

49       n-cm-01: control-module-cm shall be IP68 compliant

50

51    goal-requirement

52       g-ps-01: power-supply-ps shall provide power-pe to pump-module-pm

53       g-ps-02: power-supply-ps shall provide power-pc to control-module-cm

54       g-pm-01: pump-module-pm shall provide internal-water-flow-qi to…

55          storage-tank-st

56       g-cm-01: control-module-cm shall measure pressure-wp within storage-tank-st

57       g-cm-02: control-module-cm shall send control-signal-ce to pump-module-pm

58

59    design-requirement

60       dr-st-01: storage-capacity-v shall be at least 0.5 [m^3]

An instance of WaterStorageSystem shall accumulate water-source-flow-qs to yield stored water-volume-vs. To fulfill this function, WaterStorageSystem is composed of subcomponents power-supply-ps, pump-module-pm, control-module-cm and storage-tank-st. These components shall fulfill goal requirements g-ps-01 through g-cm-01, which define the purpose of these components with respect to each other. For example, the purpose of power-suppy-ps is to provide power-pe to pump-module-pm.

Additionally, control-module-cm shall be IP68 compliant as stated by need n-cm-01 and storage-capacity-v shall be at least $ 0.5\;{\mathrm{m}}^3 $ . The variable storage-capacity-v is a property of storage-tank-st as can be seen in the definition of StorageTank in Listing 11 (line 70).

Listing 11 contains the definitions of Battery, ControlModule, PumpModule and StorageTank, which are the definitions of the subcomponents of water-strorage-system-sts. In each definition, one can find one or more transformation requirements that define the required internal flow conversions. These transformation requirements denote the desired and thus functional dependencies between the input, output and internal variables of a component.

Transformation-requirements t-bt-01 (line 10) and t-bt-02 (line 11) define, for example, that power-supply-ps, which is an instance of Battery, shall convert internal variable power-potential-pb into the internal flow power-pi and subsequently distribute power-pi over power-pe and power-pc, which are to be provided to pump-module-pm and control-module-cm, respectively, as stated by goal requirements g-ps-01 and g-ps-02 in Listing 10 (lines 52 and 53).

In general, inputs and outputs of a component are always represented by different variables. Note, for example, water-source-flow-qs and internal-water-flow-qi, where the first variable represents the water flow flowing from the water source to the pump module, while the latter represents the internal water flow flowing from the pump module to the storage tank. Hence, when identifying and specifying the goal requirements of a component, it is often helpful to (mentally) create a free-body diagram of the respective component in which all flows crossing the boundary of the component are indicated.

ControlModule contains the subcomponents controller-ct and sensor-st. PumpModule contains the subcomponents motor-mt and pump-pm. The definitions of these components are listed in Listing 12.

Again, each of the definitions in Listing 12 contains a transformation requirement that denotes the desired input–output relations. In addition, one can find behavior requirement b-motor-torque within the definition of ElectricMotor, which defines the behavior dependencies between control-signal-ce and torque-kp.

None of these definitions have subcomponents as we have reached the leafs of the decomposition tree shown in Figure 1. However, if desired, one could easily instantiate additional subcomponents within these definitions to add an additional decomposition layer to the specification.

Listing 11: Water storage system level-2 component definitions

1 define component Battery

2    parameters

3       power-pe, power-pc is an ElectricalEnergyFlow

4

5    variables

6       power-potential-pb is an ElectricalPotential

7       power-pi is an ElectricalEnergyFlow

8

9    transformation-requirement

10       t-bt-01: shall convert power-potential-pb into power-pi

11       t-bt-02: shall distribute power-pi over power-pe and power-pc

12

13

14 define component ControlModule

15    parameter

16       power-pc is an ElectricalEnergyFlow

17       control-signal-ce is a ControlSignal

18       pressure-wp is a Pressure

19

20    variable

21       status-signal-wl is a StatusSignal

22

23    transformation-requirement

24       t-cm-01: shall convert power-pc and pressure-wp into control-signal-ce

25

26    components

27       controller-ct is a Controller with arguments

28          * power-pc

29          * control-signal-ce

30          * status-signal-wl

31       sensor-sp is a PressureSensor with arguments

32          * status-signal-wl

33          * pressure-wp

34

35    goal-requirement

36       g-ps-01: sensor-sp shall send status-signal-wl to controller-ct

37

38

39 define component PumpModule

40    parameters

41       water-source-flow-qs, internal-water-flow-qi is a LiquidMaterialFlow

42       control-signal-ce is a ControlSignal

43       power-pe is a ElectricalEnergyFlow

44

45    transformation-requirement

46       t-pm-01: shall convert control-signal-ce, water-source-flow-qs, and power-pe into internal-water-flow-qi

47

48    variables

49       torque-kp, nominal-torque-kn is a MechanicalEnergyFlow

50

51    components

52       motor-mt is an ElectricMotor with arguments

53          * control-signal-ce

54          * power-pe

55          * torque-kp

56

57        pump-pm is a Pump with arguments

58          * torque-kp

59          * water-source-flow-qs

60          * internal-water-flow-qi

61

62    goal-requirements

63       g-mt-01: motor-mt shall provide torque-kp to pump-pm with subclause

64          * s1: nominal-torque-kn shall be at least 100 [Nm]

65

66

67 define component StorageTank

68    parameter

69       water-flow-qi is a LiquidMaterialFlow

70       storage-capacity-sc is a Volume property

71       pressure-wp is a Pressure

72       water-volume-vs is a Volume

73

74    transformation-requirement

75       t-st-01: shall accumulate water-flow-qi yielding water-volume-vs and pressure-wp

Listing 12: Water storage system level-3 component definitions

1 define component Controller

2    parameters

3       power-pc is an ElectricalEnergyFlow

4       control-signal-ce is a ControlSignal

5       status-signal-wl is a StatusSignal

6

7 transformation-requirement

8 t-cl-01: shall convert status-signal-wl and power-pc into control-signal-ce

9

10

11 define component PressureSensor

12    parameters

13       status-signal-wl is a StatusSignal

14    pressure-wp is a Pressure

15

16    transformation-requirement

17       t-ps-01: shall convert pressure-wp into status-signal-wl

18

19

20 define component ElectricMotor

21    parameters

22       control-signal-ce is a ControlSignal

23       power-pe is an ElectricalEnergyFlow

24       torque-kp is a MechanicalEnergyFlow

25

26    transformation-requirement

27       t-em-01: shall convert control-signal-ce, power-pe into torque-kp

28

29    behavior-requirement

30       b-motor-torque:

31          case motor-on:

32             when

33                * c1: control-signal-ce is equal to True [−]

34             then

35                * r1: torque-kp shall be at least 100 [Nm]

36          case motor-off:

37             when

38                * c1: control-signal-ce is equal to False [−]

39             then

40                * r1: torque-kp shall be equal to 0 [Nm]

41          case fallback:

42             when no other case applies

43             then

44                * r1: torque-kp shall be equal to 0 [Nm]

45

46

47 define component Pump

48    parameters

49       torque-kp is a MechanicalEnergyFlow

50       water-source-flow-qs, internal-water-flow-qi is a LiquidMaterialFlow

51

52    transformation-requirement

53       t-pm-01: shall convert torque-kp and water-source-flow-qs into internal-water-flow-qi

5.2. Architecture derivation and visualization

A key feature of ESL is the automated derivation of a dependency graph that represents the system architecture. In this section, the working principle of the dependency graph derivation mechanism is informally explained using architecture visualizations of the water storage system example. The system architecture is visualized in graph and matrix form at all three decomposition levels. The interested reader is referend to the reference manual (Ratio Innovations B.V. 2020b) for the in-depth explanation of mathematical derivation rules. Goal, transformation, behavior and design specifications are all used to derive dependencies. This section, however, focusses on explaining how functional dependencies are derived from goal and transformation specifications.

Figure 2 shows the generated functional dependency diagram of the water storage system at decomposition level 1. This diagram shows world that contains component water-source-ws, which contains transformation requirement t-ws-01 and component water-storage-system-sts which contains transformation requirements t-sts-01. Goal requirement g-sts-01 connects transformation requirements t-ws-01 and t-sts-01.

Figure 2. Functional dependency diagram of the water storage system at decomposition level 1 (rectangle: component; hexagon: goal specification; ellipse: transformation specification).

These dependencies are derived by ‘following’ water-source-flow-qs through the system. That is, water-source-flow-qs is the output of transformation requirement t-ws-01, is transferred from water-source-ws to water-storage-system-sts as stated by goal-requirement g-sts-01 and is the input to transformationrequirement t-sts-01.

Figure 3 shows a component-function-variable multidomain-matrix (CFV-MDM) of the water storage system at the first decomposition level. The CFV-MDM is composed of three DSMs and three domain mapping matrices (DMMs). The colors of the wedges within the matrix indicate the various labels that have been assigned to a dependency based on the specification.

Figure 3. Component-function-variable multidomain-matrix of the water storage system at decomposition level 1.

The component DSM (rows, columns 1 and 2) shows the dependencies, often referred to as interfaces when the dependencies are functionally intended and designed for, between the components of the first decomposition level. A dot at position $ i,j $ indicates that component $ {c}_i $ has an interface with component $ {c}_j $ . This matrix is symmetric since if $ {c}_i $ has an interface with component $ {c}_j $ , then by definition $ {c}_j $ has an interface with component $ {c}_i $ . For example, Figure 3 shows that water-storage-system-st has a LiquidMaterialFlow interface with water-source-ws. This interface has been derived from goal requirement g-sts-01 that states that water-storage-system-st shall pump water-source-flow-qs, which is a LiquidMaterialFlow, from water-source-ws.

In practice, one should check the first DSM for missing or unexpected interfaces. A missing interface indicates an incomplete specification. An unexpected interface might indicate a specification error, such as a reference to an incorrect component.

The function DSM (rows, columns 3–5) shows the dependencies between the goal and transformation requirements. A mark at position $ i,j $ indicates that goal or transformation requirement $ {r}_i $ requires an input from goal or transformation requirement $ {v}_j $ . Figure 3 shows, for example, that transformation requirement t-sts-01 requires an input from goal-requirement g-sts-01, which in turn requires an input from transformation requirement t-ws-01. This path is the same transformation-goal-transformation path as shown in Figure 2. When creating a specification, one should check the completeness of these functional paths. An incomplete path indicates that one or more goal and transformation requirements are missing.

The variable DSM (rows, columns 6–8) shows the dependencies between the set of variables that related to the components and requirements stated within the first decomposition level of the specification. A mark at position $ i,j $ indicates that variable $ {v}_i $ depends on variable $ {v}_j $ . In the detailed design phase, one could formulate a mathematical equation or create a model for each dependency within the variable DSM to obtain an optimization model.

The component-function DMM (rows 3–5, columns 1 and 2) shows the mapping from components to goal and transformation requirements. A mark at position $ i,j $ indicates that goal or transformation requirement $ {f}_i $ is being fulfilled by component $ {c}_j $ . A transformation requirement always maps to a single component, while a goal requirement always maps to two components. This DMM can, for example, be used during change management to get an indication of which set of goal and transformation requirements might be affect when changing the design of a component.

The component variable DMM (rows 6–8, columns 1 and 2) shows the mapping of components to variables. A mark at position $ i,j $ indicates that variable $ {v}_i $ is an input, output or property of component $ {c}_j $ . This matrix provides for each component an overview of all variables that are subjects to requirements.

The function variable DMM (rows 6–8, columns 3–5) shows the mapping of goal and transformation requirements to variables. A mark at position $ i,j $ indicates that variable $ {v}_i $ is part of goal or transformation requirement $ {r}_j $ . This matrix provides an overview of which goal and transformation requirements are affected when changing the value of a variable and vice versa.

In Figure 4, the functional dependency diagram of the water storage system is shown at the second decomposition level. In this diagram, water-storage-system-sts is expanded to reveal subcomponents power-supply-ps, control-module-cm, pump-module-pm, storage-tank-st and the associated goal and transformation requirements.

Figure 4. Functional dependency diagram of the water storage system at decomposition level 2 (rectangle: component; hexagon: goal specification; ellipse: transformation specification).

Note that transformation requirement t-sts-01 is not part of Figure 4. It has been substituted by the goal and transformation requirement to be fulfilled by the subcomponents of water-storage-system-sts. Goal-requirement g-sts-01 now provides the input to transformation-requirement t-pm-01. The reason for this is that it is pump-module-pm that actually pumps water-flow-qs from water-source-ws.

Figure 5 shows the CFV-MDM at decomposition level 2. The component DSM, goal and transformation requirement DSM and variable DSM have all increased in size due to the expansions of water-storage-system-sts.

Figure 5. Component-function-variable multidomain-matrix of the water storage system at decomposition level 2.

With rows 1–4 and columns 1–4, one can see all internal interfaces between the subcomponents of water-storage-system-sts. These interfaces are directly derived from goal requirements g-ps-01 through g-cm-02 listed within Listing 10 (rows 52–57).

Note that pump-module-pm has an external interface with water-source-ws (row 5, column 1). The reason for this can be seen at position (11, 1) of the MDM, where one can see that goal requirement g-sts-01 has been assigned to pump-module-pm. That is, goal requirement g-sts-01 has automatically migrated one level down as it is pump-module-pm that actually converts water-source-flow-qs into internal-water-flow-qi. In other words, it is pump-module-pm that pumps water. Hence, pump-module-pm has to have an interface with water-source-ws.

Within the function DSM, one can observe that the goal and transformation chains have significantly increased in length. One can even identify the loop g-cm-02 $ \to $ t-pm-01 $ \to $ g-pm-01 $ \to $ t-st-01 $ \to $ g-cm-01 $ \to $ t-cm-01 $ \to $ g-cm-02. This loop represents the pressure control feedback loop. That is, based on the measured pressure within storage-tank-st, control-module-cm shall determine an appropriate value for control-signal-ce. The behavior requirements that state the logic for determining this value have not been added to this example.

The control feedback loop is also visible in Figure 4, albeit a bit more difficult to identify. Hence, for real-life systems, it is often more convenient to use the matrix visualizations as they provide better scalability.

The variable DSM (rows, columns 18–28) is extended with all variables that are used within goal and transformation requirements at the second decomposition level.

In Figure 6, the functional dependency diagram of the water storage system is shown at the third decomposition level. In this diagram, the components pump-module-pm and control-module-pm are decomposed one level further the reveal their subcomponents and associated goal- and transformation-requirements.

Figure 6. Functional dependency diagram of the water storage system at decomposition level 3 (rectangle: component; hexagon: goal specification; ellipse: transformation specification).

Goal-requirement g-sts-01 now provides input water-source-flow-qs to transformation requirement t-pm-01 which is to be fulfilled by third-level component pump-pm.

Note that Figure 6 is already becoming relatively crowded, while the decomposition tree of this small example contains only seven leaf components. This is a frequently encountered problem when using graphical modeling languages. Hence, the choice for a textual format of ESL with component by component definition of the elements in the tree.

Figure 7 shows CFV-MDM at decomposition level 3, which provides a more detailed overview of the system architecture. The component DSM (rows, columns 1–7) that water-source-ws has an interface with pump-pm, that power-supply-ps has interfaces with motor-mt and controller-ct, and that storage-tank-st has interfaces with component pump-pm and sensor-sp. Hence, the component DSM contains components that are defined at three different levels in different branches of the decomposition tree, yet provides a complete and consistent overview of all interfaces between these components. These interfaces correspond directly to the stated goal and transformation requirements.

Figure 7. Component-function-variable multi-domain-matrix of the water storage system at decomposition level 3.

Similarly, within the function DSM (rows, columns 8–23) and variable DSM (rows, columns 24–36), one can still find a complete and consistent network of dependencies, while the respective goal requirements, transformation requirements and variables are specified throughout the decomposition tree. Each dependency is directly and automatically derived based on mathematical rules.

In fact, the structured syntax and semantics allows for the automated derivation of traceability dependencies between transformation and goal requirements as well, which is often the primary motivation for creating a separate function decomposition. Figure 8 shows, for example, the traceability diagram for transformation requirement t-sts-01 which is to be fulfilled by water-storage-sts. One decomposition level down, the requirement is actually being fulfilled by the sequence of transformation and goal requirements t-pm-01, g-pm-01, and t-st-01. In turn, transformation requirement t-pm-01 is one-level down fulfilled by the sequence of goal and transformation requirements t-em-01, g-mt-01 and t-pm-01.

Figure 8. Traceability diagram for transformation requirement t-mp-01 of the water storage system.

6. Usage of the Elephant Specification Language

The earlier mentioned waterfall model (Royce 1987), spiral model (Boehm 1988), systems engineering V-model (Forsberg & Mooz 1991), onion model (Childers & Long 1994) and NASA’s systems engineering engine (Hirshorn et al. 2017) all have in common that they describe the engineering design and realization process as an iterative process in which engineers model the system at various hierarchical levels during different design phases. However, the terminology in which the process, activities and associated system models are described often differs (Maier et al. 2017).

Figure 9 merges the onion model and the NASA SE model into a variant of the V-model. We take the design process as displayed in the left-hand side of Figure 9 as our reference for writing ESL specifications.

Figure 9. Adapted version of the V-model (due to Forsberg & Mooz 1991), indicating the iterative design processes at the various decomposition levels. Design decisions at decomposition level $ i $ are input to the design process of the subcomponents at decomposition level $ i+1 $ . The developed ESL language neatly supports the specification and design process in the left-hand side of the V.

One starts at the top left at decomposition level 0 with requirements engineering (R) and system architecting (A) by specifying needs in the form of ‘the system shall…’, by specifying interactions with other components that exist within the environment the system shall operate in the form of goal requirements and by specifying internal transformations that the system will need to perform in the form of transformation requirements. Desired or required quantitative bounds on properties of the system can be added in the form of subclauses to goal and transformation requirements and design-requirements.

The interactions of the to-be-designed system with its environment, the required internal transformations and design-requirements are likely to depend on its working principle and embodiment. For example, a petrol car has a different internal working principle than an electric car, and a gasoline car may be subject to different legislation than a diesel car. Hence, the conceptual design (C) determines what working-principles are best suited for the system. Subsequently, the embodiment design (E) determines how that working-principle could be realized. The detailed design (D) is needed to verify, or at least get an indication off whether the needs and requirements can be met with the selected working principle and embodiment.

Once a working principle and embodiment at level 0 have passed the verification stage, one can move to the first validation point on the left in Figure 9. If the validation is not successful, the stated requirements and chosen working principles and embodiments are likely to be incorrect or incomplete and one has to go through the R, A, C, E, D (RACED) cycle again until the validation is successful. This is visualized by the vertical arrows in Figure 9.

Once the validation is passed, one can move on to decomposition level 1, where one can start to specify the subcomponents of the system following the chosen working principle and embodiment. This neatly aligns with the component centered perspective of ESL, which takes the system decomposition as the central structure of the specification. The system decomposition at level $ i $ follows from the design decisions made at level $ i-1 $ . For each of these subcomponents, one again follows the RACED cycle until one reaches the second validation point and one can progress to the third level, further decomposing the system.

This process continues until one reaches a sufficiently detailed specification and design to move on to the right side of the V-model. At each level and during each RACED activity, ESL and the generated dependency graph and visualization can be used for efficient requirements management and interface management. Additionally, one can generate PDF and Excel documents for different stakeholders from the same source using the document generation functionality integrated within the ESL tooling (Ratio Innovations B.V. 2022). This ensures the consistency among these documents. Of course, one will need to use other engineering software as well to do detailed simulations and create geometric models. At each level of the decomposition and throughout the development cycle, one can generate the architecture model and analyze it with architecture analysis tools such as those of Paparistodimou et al. (2020) to improve the architecture. Albers et al. (2019) demonstrated how MBSE can support modular design and evaluated their framework for five case studies, one of which about requirements engineering. The ESL tooling comes with integrated DSM analysis and clustering tools to support the multilevel architecture analysis.

In particular application cases, we experienced that it may also be effective to start lower in the decomposition tree. When applying ESL during the design of several advanced research setups for the Dutch Institute of Fundamental Energy Research (DIFFER; http://www.differ.nl/), we experienced that the early design process happened to be rather organic and that the system decomposition tree frequently changed as new (better) ideas came up, requirements changed, or concepts turned out not to be feasible. The research setups required the integration of very specific sets of off-the-shelf diagnostic tools to study highly specific physical phenomena. For these diagnostic tools, there exist only a few suppliers in the world. Furthermore, another requirement was to leverage experience obtained with previous setups as much as possible. Consequently, the desired systems are unique and new-to-the-world. Yet many of the components of these systems are off-the-shelf. This resulted in a rather bottom-up design process in which the challenge was to realize a system in which the physical phenomena could be realized, controlled and studied with the required diagnostic tools.

ESL can support both a top-down, bottom-up or mixed engineering design process. ESL components can represent off-the-shelf components, conceptual ‘blobs’ which are in the very early design phase, or anything in between. All can exist within the same specification allowing the specification to evolve over time as more information about the system becomes available. Through the use of a single decomposition tree and by employing the goal and transformation statements in a hierarchical tree, ESL can automatically generate and maintain the mappings within and between all levels and branches of the decomposition tree as explained in Section 5.2.

Hence, ESL can be used during the design of both mature and new-to-the world systems. Beernaert et al. (2024b), for example, have used ESL throughout the design process of an optical plasma diagnostic system for nuclear fusion power plant ITER, which is currently being constructed in France.

Additionally, different branches of the decomposition tree may have different numbers of levels. This provides flexibility in modeling the various parts of the system at different levels of granularity. In general, we advise to stop decomposing a system once one reaches off-the-shelf components or components that can be designed and realized by a relatively small design team. The granularity of leaf-components in the decomposition tree depends therefore on the particular design challenge. In the specification of a pulsed-laser deposition research cluster designed for DIFFER, for example, the leaf components ranged from individual pressure sensors at decomposition level 3 to a full X-ray photoelectron spectroscopy system at decomposition level 1, both being off-the-shelf components. Albeit that the latter is a hundred-thousand times more expensive than the prior. For more guidelines on how to use ESL in practice, the reader is referred to the ESL specification 101 pages (Ratio Innovations B.V. 2023).

ESL has shown to be a flexible language allowing one to create specifications and derive architecture models for both new and (partially) existing systems following a top-down, bottom-up or rather organic process that can evolve over time. This evolution of ESL specifications can be easily managed using conventional version control software such as GIT and SVN due to the text based nature of ESL. That is, one can create different branches to explore different concepts, generate different architectures and compare discuss them, and merge them if desired.

The semantics and use of ESL has commonalities with IDEF0, a long existing standard for functional modeling (see, e.g., the book by Buede 2009). Both build upon functions, flows and decomposition. The fundamental difference is that IDEF0 takes a (transformation) function centric approach, while ESL is component-centric. ESL associates the transformation functions to the components and uses goal functions to specify the flows between components.

In ESL, decomposition of a component implies that the transformation functions embodied by the component are represented in greater detail by subcomponents and their transformation and goal functions. So, in ESL, function decomposition takes place through the transformation functions, similar to IDEF0.

ESL may look at first glance oriented on modeling physical architectures. However, by adopting the method of use of ESL, as explained in this section, and by taking care that the choice of nouns for the components is sufficiently solution free, ESL actually enables a combined approach to functional and physical architecture modeling. The allocation of goal and transformation functions naturally follows design decisions on working principles and embodiments through all levels of the system decomposition and may be revised and detailed as the system architecting progresses.

What is more, other types of requirements, such as performance and design requirements, can be intuitively associated with the various functions, flows, variables and components, providing for the desired bridge between requirements engineering and systems architecting.

7. Concluding remarks

Writing ‘high-quality’ system specifications is essential to the success of a design project (Buede (2009)). In this article, we present a novel textual specification language, named ESL, which enables the structured specification of a system’s functions, behavior and design in terms of needs, requirements and constraints at various levels of granularity following the systems engineering V-model.

Components are the basic building blocks of an ESL specification. Needs, (function/behavior/design) requirements and (function/behavior/design) constraints are specified within component definitions. ESL distinguishes between goal-function and transformation-function requirements and constraints. Goal functions denote the purpose of components with respect to other components within the system. Transformation functions describe the internal flow conversion processes in a component. Design specifications denote bounds on variables that describe the design of a system.

A compiler has been developed that checks the consistency of ESL specifications and derives dependencies between components, variables, needs, goal specifications, transformation specifications, design specifications, relations and combinations thereof across all decomposition levels of the specification, following a predefined set of mathematical rules. This provides a major added value compared to existing architecture modeling tools where the assignment or derivation of such dependencies typically has to be ad hoc implemented and checked for correctness and consistency, which is labor intensive and error prone.

Dependencies between specification elements can be visualized at each decomposition level in graph or multidomain-matrix (MDM) form. This is illustrated for a small example problem. The general method of use of ESL closely aligns with the commonly used SE V-model. This has been exemplified by presenting a variant of the V-model that stresses the iterative decomposition-based design and development process. The system decomposition is the central tree in writing the ESL specifications, which follows the design concept and embodiment decisions. The graphs and MDMs clearly show the dependencies between components, goal functions, variables and combinations thereof. By analyzing the network of dependencies, one can gain insight into the (functional) system architecture.

A specification language such as ESL has the potential to reduce ambiguity and inconsistencies in system specifications. Moreover, by automatically deriving all dependencies between a system’s components, functions and variables, engineers can quickly increase their understanding of the specified system and optimize the system architecture, effectively blending requirements engineering with systems architecting. This is the main added value of the proposed language.

The ESL compiler and all associated visualization and analysis tooling has been made open-source and freely available within an online repository (https://pypi.org/project/raesl/) to allow for easy and wide spread adoptation and further development among systems engineers and architects.