Quoting [PB07], ‘Engineering design concerns 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 [HJD17]. Design engineers have to interpret these system specifications and convert them into technical designs.
An important step in the conversion of needs, requirements and constraints into technical solutions is the design of the system’s architecture, for multiple reasons [Egg05]. First of all, the system’s architecture has a significant impact on the system’s performance, e.g., reliability, availability, maintainability, and cost of the system [JSS07, LST09]. Secondly, insight into the system’s architecture is required for effective change management [GdWB+09]. That is, requirements often change during the design process, which may cause re-design of one or more components. Such design changes may propagate through the system yielding re-design of other components [JECC11]. A model of the system architecture can be used to evaluate the impact of design changes [CSE04].
It is common practice to relate needs, requirements, and constraints to technical aspects of the system [HJD17, PB07]. Therefore, engineers need methods to structure, visualize, and analyze the relations between system architecture, needs, requirements, and constraints.
[Ulr95] defines system architecture as the mapping of a system’s functions to the physical components within the system, and to the dependencies between those components. The work of [WERV18a], shows that the intended system architecture can be derived from structured function specifications. That is, using a fixed grammar to describe component functions, we can automatically derive dependencies between components, between functions, between variables, and combinations thereof, and visualize those dependencies. This presents an effective method to generate a dependency structure matrix (DSM) model of the system architecture.
The method of [WERV18a], however, is limited to a single level description of the system. The functions are specified at a single granularity level. Design processes are usually hierarchical in nature [Est07]. Different parts of a system are usually described at different levels of granularity in system specifications [MEC17]. As the design process progresses, the level of granularity of system specifications may change. That is, as more details of the system become apparent, the grain size at which a system is described becomes smaller [EJOT14].
Furthermore, in [WERV18a] functions of the system at hand are described and therefore only intended functional dependencies can be derived. In engineering design, however, the design, behavior and physics of systems is specified and analysed as well. It is essential to have insight in the network of design dependencies, e.g. a spatial dependency between two components that have to fit in a predefined space, logical dependencies, e.g. (software) dependencies between sensors and actuators, and physical dependencies, e.g., heat exchange due to dissipation of energy.
Therefore, we took the concepts [WERV18a] as a basis and developed the Elephant Specification Language (ESL). ESL is a computer readable language for writing multiple level system specifications that describe the function, behavior, design and physics of a systems and its subcomponents at various levels of granularity. An ESL-compiler has been developed which checks the consistency of ESL specifications and derives dependencies between components, variables, needs, goal-specifications, transformation-specifications, behavior-specifications, design-specifications, relations, and combinations thereof across all decomposition levels of the specification, following a predefined set of mathematical rules.
The outline of this manual is as follows. The Related work section elaborates on the typical elements of a system specification and how these elements are described. Additionally, the Related work briefly discusses existing methods for the creation of system specifications. In the Syntax and semantics section, the syntax and semantics of the various elements of ESL are explained. In the Dependency derivations section we discuss the mathematical rules that are used to derive dependencies between ESL elements such as components, functions, and variables.