1. Introduction
Pahl & Beitz (Reference Pahl and Beitz2007) 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 Reference Hull, Jackson and Dick2017). 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 Reference Madni and Sievers2018; De Saqui-Sannes et al. Reference De Saqui-Sannes, Vingerhoeds, Garion and Thirioux2022; Campo et al. Reference Campo, Teper, Eaton, Shipman, Bhatia and Mesmer2023; Wilking et al. Reference Wilking, Horber, Goetz and Wartzack2024).
An important step in the conversion of needs, requirements and constraints into technical solutions is the design of the system’s architecture (Eggert Reference Eggert2005). 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 Reference Jiao, Simpson and Siddique2007; Lough, Stone & Tumer Reference Lough, Stone and Tumer2009). Second, insight into the system’s architecture is required for effective change management (Giffin et al. Reference Giffin, de Weck, Bounova, Keller, Eckert and Clarkson2009). 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. Reference Jarratt, Eckert, Caldwell and Clarkson2011). A model of the system architecture can be used to evaluate the impact of design changes (Clarkson, Simons & Eckert Reference Clarkson, Simons and Eckert2004).
It is common practice to relate needs, requirements and constraints to technical aspects of the system (Pahl & Beitz Reference Pahl and Beitz2007; Hull et al. Reference Hull, Jackson and Dick2017). 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. (Reference Wilking, Horber, Goetz and Wartzack2024) as one of the use case categories in MBSE.
Ulrich (Reference Ulrich1995) 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. Reference Wilschut, Etman, Rooda and Vogel2018b), 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 (Reference Crilly2013). 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 Reference Steward1981) of the system architecture. Eppinger & Browning (Reference Eppinger and Browning2012) 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. (Reference Wilschut, Etman, Rooda and Vogel2018b), 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 Reference Estefan2007). Different parts of a system are usually described at different levels of granularity in system specifications (Maier, Eckert & Clarkson Reference Maier, Eckert and Clarkson2017). 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. Reference Eppinger, Joglekar, Olechowski and Teo2014).
Furthermore, in Wilschut et al. (Reference Wilschut, Etman, Rooda and Vogel2018b), 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. Reference De Saqui-Sannes, Vingerhoeds, Garion and Thirioux2022), 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 (Reference Eckert, Stacey and Clarkson2003). 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. (Reference Wilschut, Etman, Rooda and Vogel2018b).
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. Reference Wilschut, Etman, Rooda and Vogel2018a), high-tech (Meeusen et al. Reference Meeusen, Etman, Wilschut, Peijnenburg and Segers2019; Kools Reference Kools2022), maritime (Herremans et al. Reference Herremans, Wilschut, Deul, Vink and Brouwer2022) and fusion engineering and related big-science projects (Beernaert et al. Reference Beernaert, de Baar, Etman, Classen and de Bock2024a , Reference Beernaert, Verlaan, De Bock., Moser, Etman, Classena and De Baarb ), 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 Reference Buede2009). 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 Reference Hooks1994; Grady Reference Grady2014; Hull et al. Reference Hull, Jackson and Dick2017). 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 Reference Royce1987), the spiral-model (Boehm Reference Boehm1988), the V-model (Forsberg & Mooz Reference Forsberg and Mooz1991) and the onion model (Childers & Long Reference Childers and Long1994). 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 Reference Suh1998; Dym & Brown Reference Dym and Brown2012; Pahl & Beitz Reference Pahl and Beitz2007) and the subsequent manual mapping of components to functions and variables. Crilly (Reference Crilly2013) 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 (Reference Crilly2013) introduced new function terminology. Crilly (Reference Crilly2013) 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 (Reference Eisenbart, Blessing and Gericke2012), which are used by Wilschut et al. (Reference Wilschut, Etman, Rooda and Vogel2018b). 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 (Reference Crilly2013) 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 Reference Eppinger and Ulrich2015). Needs describe what is wanted by the customer. Needs are typically qualitative, imprecise and ambiguous due to their linguistic origins (Jiao & Chen Reference Jiao and Chen2006).
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. Reference Ericson, Müller, Larsson and Stark2009; Cascini, Fantoni & Montagna Reference Cascini, Fantoni and Montagna2013). This is in line with the work of Jiao & Chen (Reference Jiao and Chen2006) 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 Reference Glinz2007). 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 (Reference Koelsch2016). 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. (Reference Hull, Jackson and Dick2017) 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 (Reference Cohen1990) defined linguistic equivalents for mathematical inequality operators, Hooks (Reference Hooks1994) debate the usage of the word ‘shall’ in requirements and van Vliet (Reference van Vliet2005) 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. Reference Arora, Sabetzadeh, Briand and Zimmer2014; Mahmud, Seceleanu & Ljungkrantz Reference Mahmud, Seceleanu and Ljungkrantz2017).
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 Reference Koelsch2016). This motivated the increasing popularity of ontology-driven requirement engineering (Chen et al. Reference Chen, Chen, Leong and Jiang2013; Dermeval et al. Reference Dermeval, Vilela, Bittencourt, Castro, Isotani, Brito and Silva2015), 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 Reference Fernandes and Machado2016; Koelsch Reference Koelsch2016). A similar classification of requirements is made in the NASA Systems Engineering handbook (Hirshorn, Voss & Bromley Reference Hirshorn, Voss and Bromley2017): 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. (Reference Eisenbart, Blessing and Gericke2012), 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. (Reference Wilschut, Etman, Rooda and Vogel2018b), 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 (Reference Stone and Wood2000) and Hirtz et al. (Reference Hirtz, Stone, McAdams, Szykman and Wood2002)), 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. Reference Umeda, Ishii, Yoshioka, Shimomura and Tomiyama1996), the Structure–Behavior–Function model (Goel, Rugaber & Vattam Reference Goel, Rugaber and Vattam2009; Komoto & Tomiyama Reference Komoto and Tomiyama2012) and the requirements engineering book of Hull (Hull et al. Reference Hull, Jackson and Dick2017). 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 Reference Koelsch2016). 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 Reference Pahl and Beitz2007).
Hull et al. (Reference Hull, Jackson and Dick2017) 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 (Reference Crilly2013) and Wilschut et al. (Reference Wilschut, Etman, Rooda and Vogel2018b). 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 (Reference Pahl and Beitz2007)). 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. Reference Eppinger, Joglekar, Olechowski and Teo2014). 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 Reference Tilstra, Seepersad and Wood2012), making it impossible for a single person to oversee all dependencies (Sosa, Eppinger & Rowles Reference Sosa, Eppinger and Rowles2007). 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 Reference Friedenthal, Moore and Steiner2014).
Written documents, however, remain the primary means of documentation and communication in engineering design (Tomiyama et al. Reference Tomiyama, van Beek, Alvarez Cabrera, Komoto and D’Amelio2013). This may be due to the limited scalability of graphical specification methods (Tosserams et al. Reference Tosserams, Hofkamp, Etman and Rooda2010). 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. Reference De Gea, Nicolás, Alemán, Toval, Ebert and Vizcaíno2012 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. Reference Arora, Sabetzadeh, Briand and Zimmer2014; Hull et al. Reference Hull, Jackson and Dick2017; Mahmud et al. Reference Mahmud, Seceleanu and Ljungkrantz2017). 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. (Reference Ghosh, Elenius, Li, Lincoln, Shankar and Steiner2016) and Mustafa, Kadir & Ibrahim (Reference Mustafa, Kadir and Ibrahim2017) 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 (Reference Kuhn2014) 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. (Reference Clark, Harrison, Jenkins, Thompson and Wojcik2005), 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 (Reference Fuchs, Kaljurand and Kuhn2008) 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. (Reference Mavin, Wilkinson, Harwood and Novak2009) 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 (Reference Feiler, Delange and Wrage2016) 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. Reference Tosserams, Hofkamp, Etman and Rooda2010) and the z-language (Woodcock & Davies Reference Woodcock and Davies1996) 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. (Reference De Saqui-Sannes, Vingerhoeds, Garion and Thirioux2022) 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 Reference Dori, Reinhartz-Berger and Sturm2003). 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. (Reference De Saqui-Sannes, Vingerhoeds, Garion and Thirioux2022) 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. (Reference De Saqui-Sannes, Vingerhoeds, Garion and Thirioux2022) 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. 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. the automated derivation of dependencies between components, function specifications, design specifications, behavior specifications and combinations thereof from the specification themselves;
-
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. Reference Erden, Komoto, van Beek, D’Amelio, Echavarria and Tomiyama2008). This may seem to be in contradiction to scholars who advocate ‘solution-free’ modeling, such as Pahl & Beitz (Reference Pahl and Beitz2007) and Stone & Wood (Reference Stone and Wood2000), 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. (Reference Caldwell, Thomas, Sen, Mocko and Summers2012) 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 Reference Crilly2013). 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. Reference Tilstra, Seepersad and Wood2012), 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 Reference Deng2002). 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. (Reference Hirtz, Stone, McAdams, Szykman and Wood2002), which all have a distinct definition.
4.4. Needs
Needs are informal statements on what is desired (Jiao & Chen Reference Jiao and Chen2006). 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. (Reference Wilschut, Etman, Rooda and Vogel2018b) 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. (Reference Wilschut, Etman, Rooda and Vogel2018b), 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 Reference Beernaert and Etman2019).
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. Reference Wilschut, Etman, Rooda and Vogel2018a), fusion engineering and big science (Beernaert et al. Reference Beernaert, Etman, De Bock, De Baar and Classen2022 , Reference Beernaert, de Baar, Etman, Classen and de Bock2024a , Reference Beernaert, Verlaan, De Bock., Moser, Etman, Classena and De Baarb ), the maritime industry (Herremans et al. Reference Herremans, Wilschut, Deul, Vink and Brouwer2022) and high tech (Meeusen et al. Reference Meeusen, Etman, Wilschut, Peijnenburg and Segers2019; Kools Reference Kools2022).
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. (Reference Wilschut, Etman, Rooda and Vogel2018b)) 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 Reference Royce1987), spiral model (Boehm Reference Boehm1988), systems engineering V-model (Forsberg & Mooz Reference Forsberg and Mooz1991), onion model (Childers & Long Reference Childers and Long1994) and NASA’s systems engineering engine (Hirshorn et al. Reference Hirshorn, Voss and Bromley2017) 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. Reference Maier, Eckert and Clarkson2017).
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 Reference Forsberg and Mooz1991), 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. (Reference Paparistodimou, Duffy, Whitfield, Knight and Robb2020) to improve the architecture. Albers et al. (Reference Albers, Bursac, Scherer, Brik, Powelske and Musschik2019) 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. (Reference Beernaert, Verlaan, De Bock., Moser, Etman, Classena and De Baar2024b), 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 Reference Buede2009). 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 (Reference Buede2009)). 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.
Acknowledgements
We would like to thank Walter Nieman, Erik-Jan Houwing, Maria Angenent and Robert de Roos for their feedback and support for this work. We would also like to thank the anonymous reviewers for their comments and suggestions, which have improved the article.
Financial support
Financial support for this research by Rijkswaterstaat, part of the Dutch Ministry of Infrastructure and Water Management, is gratefully acknowledged.
Open access
