A requirement-driven architecture definition approach for conceptual design of mechatronic systems

Abstract

Designers specify design requirements and determine the interconnections between the design requirements and main components of the system architecture during the conceptual design phase. To define the architecture of a mechatronic system, two research issues, namely system decomposition and component selection, should receive special attention. However, the manner in which to realise system decomposition and component selection by using the requirement specification results, to achieve an appropriate system architecture, has seldom been investigated in existing studies. Therefore, the authors present a requirement-driven architecture definition approach to solve the system decomposition and component selection problems. A well-formulated specification of design requirements is proposed, which classifies design requirements into functional and non-functional requirements. Moreover, a decomposition method based on the functional requirements is presented to help designers realise system decomposition, while a component selection method based on the non-functional requirements is proposed to help designers select the most suitable components. The lunar roving vehicle and automated ceramic matrix composite materials cutting system are selected as two case studies to demonstrate the application of the proposed approach in both the academic and industrial domains.

Keywords

Mechatronic system conceptual design system decomposition component selection multi-attribute decision-making model

1. Introduction

Mechatronics is typically characterised by an integration of mechanical, electrical/electronic, and software engineering [1]. At present, expanding disciplines and technologies, such as optics, robotics, cloud computing, and big data analytics, have gradually been integrated into the development of mechatronic systems [2]. As a result, the traditional sequential design process, in which every discipline is developed independently and sequentially, is no longer suitable for the design of mechatronic systems [3]. High-level multidisciplinary integration cannot be achieved if the involved disciplines are not considered simultaneously [4]. However, this approach increases the time-to-market and development costs [5].

Systems engineering is proposed as an effective support for solving the problem relating to multidisciplinary integration for the development of complex systems, which may be defined in numerous manners [6]. The definition that has been widely accepted was proposed by the ISO committee. ISO/IEC 15288 defines systems engineering as “an interdisciplinary approach governing the total technical and managerial effort required to transform a set of stakeholder needs, expectations, and constraints into a solution and to support that solution throughout its life” [7]. Conceptual design is one of the most important design phases in systems engineering, during which designers should ideally consider practical issues of the balance between meeting customer requirements on basic functionalities [8], solution optimisation [9], and control simplicity [10], among others, and determine how to link these requirements to an appropriate system architecture. According to ISO/IEC/IEEE 42010, system architecture refers to “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” [11]. Therefore, two research issues that should be paid special attention for the architecture definition are as follows: (1) the manner in which to decompose a mechatronic system into components; and (2) the manner in which to select suitable components among various alternatives. The former research issue raises the system decomposition problem, while the latter relates to the component selection problem.

System decomposition refers to the process in which a mechatronic system is eventually decomposed into components [12]. According to the customer requirements, the main functions of the mechatronic system should be embodied in the system architecture, in which the main sub-systems of the mechatronic system are determined. The decomposition process will then be applied recursively until discipline-specific components are achieved.

Moreover, component selection is a critical issue for architecture definition, and it focuses on the selection of suitable components among various alternatives to achieve an ideal combination [13]. Drake underlined the importance of component selection as follows: during the conceptual design phase, if incorrect components are selected, the design requirements will be not satisfied; if sub-optimal components are selected, the system solution will be sub-optimal [14].

The above introduction indicates that, to define the system architecture, by considering design requirements, designers should firstly decompose the mechatronic system into components and then select suitable components among various alternatives. However, research questions such as which roles the design requirements should play in the architecture definition, and how to use design requirements to support the architecture definition, have seldom been discussed in existing design methods.

The paper proposes a requirement-driven architecture definition approach, with the intention of presenting a formalised conceptual design process, from the specification of design requirements to the final architecture definition, by focusing on the aforementioned system decomposition and component selection problems. A decomposition method is proposed to solve the system decomposition problem. Moreover, to solve the component selection problem, a component selection method based on a multi-attribute decision-making (MADM) model is adopted.

The remainder of this paper is organised as follows. Section 2 reviews the current requirement specification approaches for mechatronic systems. Section 3 introduces the proposed requirement-driven architecture definition approach, including the system decomposition and component selection methods. In Section 4, the lunar roving vehicle and automated ceramic matrix composite (CMC) materials cutting system are presented as two case studies to demonstrate the application of the proposed approach in both the academic and industrial domains. Detailed discussions of the proposed design approach are provided in Section 5. Finally, conclusions are drawn in Section 6.

2. Literature review

Conceptual design begins with a specification of the design requirements, which addresses the problems that the designers must solve [15]. When specifying the design requirements, designers should consider not only what customers require, but also all requirements relating to the entire product life cycle. With the Industry 4.0 concept, fulfilling individual customer requirements to develop customisable products is becoming a more important factor in determining the competitiveness of an enterprise [16]. Certain large and complex systems, such as power plants, should be designed completely according to customer requirements. Other types of customisable products, such as ships, cars, and robotic cellular systems, among others, differ from power plants, and are designed and assembled from configured components or modules that vary according to the customer requirements [17]. When large numbers of customised products are created, attempts will be made to apply the principles of mass customisation, which allows for fulfilling the expectations of every customer by adjusting a product to their requirements [16, 18]. However, successful products should be introduced into the market as quickly as possible; thus, companies must have a very solid idea of the entire life cycle of each product [18]. From the product life cycle perspective, the requirements originating from other processes of the product life cycle, such as production, maintenance, and even recycling processes, should also be considered during the early design phase of the product. If such requirements are effectively specified before entering the design process, firstly, the completeness and consistency of information generated during the different processes of the product life cycle can be ensured; secondly, design errors owing to ignorance of the requirements relating to the following processes can be avoided, and the number of unnecessary design iterations can therefore be significantly reduced.

A clear and well-formulated specification of design requirements is vital for an appropriate system architecture, which should cover all activities relating to discovering and documenting the requirements [19, 20]. The process for specifying design requirements consists of: (1) the capturing of informal requirements, and (2) the classification of the informal requirements from which designers can follow and define the system architecture [21]. Current studies closely related to the capturing of informal requirements and requirement specifications will be reviewed hereafter.

2.1 Capturing of informal requirements

The capturing of informal design requirements is not merely a mathematical or technological challenge, but rather a complex social process [22]. Various methods have been proposed to deal with this process. Loucopoulos and Champion adopted domain knowledge to translate informal requirements into formal representations [23]. In their proposition, the informal requirements were obtained through interviewing techniques. Besbes et al. believed that fuzzy ontologies could be used to represent the informal information in natural language and allow for the interpretation of its ambiguity. They proposed a semantic and fuzzy representation which allowed the user informal requirements to be expressed in a formal, structured, and layered manner [24]. Macaulay proposed a cooperative approach to capture customer requirements [22]. This cooperative approach was implemented by making use of face-to-face meetings organised by a so-called “facilitator”, who is external to the stakeholders of the design team. However, a series of meetings are required in the cooperative approach, which are costly and time consuming. Bahill and Madni believed that the so-called “problem statement” was the key part to generate an unambiguous requirement specification [25]. According to these authors, the problem statement is intended “to articulate the customer needs, project goals, business needs, required system capabilities, system scope, concept of operations, stakeholders, deliverables, and key decisions that need to be made”. When the problem statement is completed, designers should verify it with the customers until the problem statement is clear, unambiguous, at the correct level and properly scoped. To obtain the problem statement, Carroll proposed a promising approach by applying scenarios to identify the product requirements [26]. Scenarios are sequences of events with a narrative structure, and Carroll believed that walking through the problem scenarios of one product could aid designers in discovering and capturing emergent requirements. Seyff et al. further developed the scenarios-based design proposed by Carroll, and proposed a promising approach in which possible scenarios are illustrated by use cases to aid designers in identifying design requirements [27].

2.2 Requirement specifications

Once the informal design requirements have been captured, they should be classified and analysed so that designers can achieve an appropriate system architecture. Therefore, it is necessary to develop an appropriate requirement classification method to provide designers with further information for the two issues (system decomposition and component selection) of the system architecture definition during the conceptual design phase.

To provide designers with a well-formulated specification of the design requirements, different classification methods for requirements have been proposed. Freeman believed that quality is the most important factor for the systems engineering process, and pointed out that requirements can be considered as a combination of requirements relating to basic quality (functionality, reliability, ease of use, economy, and safety) and additional quality (flexibility, reparability, adaptability, understandability, documentation, and enhanceability) [28]. Chen and Zeng categorised requirements into eight levels according to the priority of each requirement during the design process: natural laws; social laws and regulations, technical limitations; cost, time, and human resources; basic functions; extended functions; exception control levels; and human-machine interfaces [29]. Hehenberger classified requirements into the following groups: global, cumulative, specific, and interconnected requirements [30]. Roman proposed that requirements can generally be classified as functional and non-functional requirements [31]. According to the definition provided by Thayer and Dorfman, a functional requirement is a requirement that specifies a certain function that a system or component must be capable of performing [32]. That is, functional requirements define what the system will do. However, non-functional requirements describe the manner in which the system will do it, such as performance requirements, external interface requirements, design constraints, and quality attributes [33].

The classification of requirements into functional and non-functional requirements has been widely adopted in software development, and certain researchers have provided additional details regarding the two types of requirements. Chung et al. analysed the non-functional requirements used for software development, such as accessibility, accountability, and accuracy [34]. Mylopoulos et al. further classified non-functional requirements into quantitative and qualitative requirements [35]. Mariza et al. proposed 114 non-functional requirements based on the analysis results of Chung et al. [36]. Zhu et al. proposed a non-functional requirements tradeoff model to evaluate non-functional requirements and the relationships among them [37]. Letier et al. stated that certain non-functional requirements might not be completely satisfied, and proposed a decision-making method for alternative design based on the satisfaction degree of non-functional requirements [38].

This paper adopts the classification method proposed by Roman; that is, the authors classify the requirements as functional and non-functional requirements. Although the previous literature review demonstrates that research works have been carried out based on this classification method in software development, the manner in which to achieve an appropriate system architecture for mechatronic systems using the results of requirement specification has seldom been addressed by existing studies. The proposed requirement-driven architecture definition approach is detailed in the following section.

3. Requirement-driven architecture definition approach

The proposed design approach focuses on two research problems relating to the architecture definition for mechatronic systems: system decomposition and component selection. In the requirement-driven architecture definition approach, functional requirements aid designers in realising system decomposition, while non-functional requirements enable designers to solve the component selection problem. The details of the proposed approach will be presented hereafter.

3.1 System decomposition

In this section, the system decomposition method is discussed in further detail. Functional requirements can provide initial information regarding the main architecture. Following the recursive decomposition process for the mechatronic system, the discipline-specific components of the mechatronic system can eventually be achieved.

3.1.1 Specification of functional requirements

Functional requirements define the system behaviours; that is, the fundamental process or transformation that the system components perform on inputs to produce outputs [39]. Functional requirements can be used to describe not only the overall system behaviours, but also the behaviours of every sub-system; therefore, a hierarchical structure constructed with functional and sub-functional requirements can be used to represent functional requirements. Various modelling languages and tools, such as SysML,1 3DEXPERIENCE,2 etc., have been developed to represent such a hierarchical structure of functional requirements.

Thereafter, the functional structure of the mechatronic system can be proposed according to the specification results of the functional requirements. The functional structure is of great significance, as it links the design requirements to the system architecture. Therefore, the hierarchical structure can also be used to represent the main system functions and sub-functions. Such a hierarchical functional structure can be created by organising sub-functions that can satisfy certain functional requirements [40].

The architecture definition for mechatronic systems begins once the functional structure proposed according to the specification results of the functional requirements has been constructed. However, to define the system architecture, the main sub-systems should be further decomposed into multidisciplinary components. The following sub-section presents the system decomposition methods.

Figure 1.

UML activity diagram for component decomposition method [41].

3.1.2 Decomposition method

As discussed previously, the system and its main sub-systems can be obtained by specifying and embodying the functions and main sub-functions at the system-level.

The authors have proposed the component decomposition method to aid designers in achieving the appropriate hierarchy for the architecture of mechatronic systems. Figure 1 illustrates the steps of the proposed decomposition method. Moreover, designers should further decompose the interfaces between the components while carrying out the component decomposition process. For additional details on the component and interface decomposition method, interested readers are referred to [41].

3.2 Component selection

This general architecture is proposed to fulfil the functional requirements that have been specified during the previous design phase. However, according to Vareilles et al., a system architecture is composed of one set of requirements and one or more solutions (or component alternatives) [42]. Following system decomposition, a general architecture of the mechatronic system can be achieved. This general architecture is proposed to fulfil the functional requirements that have been specified during the previous design phase. However, a complete architecture of a mechatronic system requires designers not only to propose a hierarchical structure for components by decomposing the system, but also to select the most suitable components among various alternatives. In this paper, the authors propose criteria by specifying the non-functional requirements to select the most suitable components. The details of the component selection process are presented in the following sections.

3.2.1 Specification of non-functional requirements

Non-functional requirements constrain the manner in which the system behaves regarding certain observable attributes [43]. Neglecting non-functional requirements carries the risk of design failures, such as poor quality and customer dissatisfaction [44]. Therefore, considering non-functional requirements during the early design phase of the mechatronic system will significantly reduce design errors, design costs, and development leading times.

Various propositions for non-functional requirement types in software development have been proposed by previous researchers. However, the classification of non-functional requirements for the design of mechatronic systems has seldom been addressed. Therefore, the authors propose a new list of non-functional requirements by carefully analysing the proposition of Mairiza et al.

Figure 2.

Non-exhaustive list of non-functional requirements for mechatronic systems.

Mairiza et al. proposed a list of non-functional requirements for software development following the investigation of 182 information sources published over the past three decades. The list presents 114 types of non-functional requirements, which cover most non-functional requirements for software development. This list provides designers with a useful reference for specifying non-functional requirements in mechatronic systems, because software is considered as one of the key parts of mechatronic systems. However, the non-functional requirements for the hardware part of mechatronic systems (such as electrical/electronic and mechanical components) have not been included in this list. Thus, the authors propose a list of non-functional requirements based on the list of Mairiza et al. regarding the specificities in the design of mechatronic systems. The principles for the proposition of the new list of non-functional requirements for mechatronic systems are presented as follows.

•

Most terminologies in the list of non-functional requirements for software development can be retained, but their meanings should be broadened and redefined from the viewpoint of mechatronic systems. For example, the requirement “Accessibility/Access Control” means that the software should be accessed and controlled by users in the software context. However, this meaning should be broadened and redefined as “the mechatronic system should be accessed by users” in the new list, because software is only one part of the mechatronic system. This type of terminology is indicated in black in Fig. 2.

•

Certain terminologies in the list are used only in the software domain, thus, these should be replaced with other terminologies that can be used in software and hardware domains simultaneously to represent the same meanings. For example, the requirement “Debuggability” means that the software should allow designers/users to locate and correct errors in the program code. In the new list of non-functional requirements, the requirement “Correctability” is proposed to replace “Debuggability”, because the mechatronic system should allow designers/users to locate and correct not only errors in the program code, but also those in the hardware. This type of terminology is indicated in blue in Fig. 2.

•

Terminologies that describe the non-functional requirements for hardware parts of mechatronic systems should be added to the list. The list proposed by Mairiza et al. does not include non-functional requirements relating to the physical attributes for hardware parts of mechatronic systems, such as the size and weight. This type of terminology is highlighted in green in Fig. 2.

•

The importance of perspective of the product life cycle has been discussed in Section 2. However, the non-functional requirements relating to the entire product life cycle have not been fully considered in the list proposed by Mairiza. Therefore, the authors propose certain terminologies for non-functional requirements, such as Deliverability, Recyclability, Productivity and Process Management Time. The non-functional requirements relating to the product life cycle are indicated in purple in Fig. 2.

•

The proposed list of non-functional requirements for mechatronic systems can be modifiable, and new terminologies that describe certain special non-functional requirements can be added to the list according to special customer needs or designers’ understanding of the mechatronic system. For example, for mechatronic systems that operate in extreme environments, several special non-functional requirements, such as Heat Resistance and Corrosion Resistance, may be proposed by users or designers. This type of non-functional requirement is indicated in red in Fig. 2.

Figure 2 presents a non-exhaustive list of non-functional requirements proposed by the authors. The authors wish to point out that the non-functional requirements used by designers to evaluate a mechatronic system stem from the information provided by stakeholders and usage scenarios. That is, designer experiences aid in deriving the non-functional requirements from the aforementioned information. The proposed list can be used as a general reference to help designers select non-functional requirements and evaluate the manner in which the mechatronic system realises the functions. Therefore, different non-functional requirements should be selected according to varying design contexts, and it is not necessary to use all of the listed non-functional requirements to evaluate a mechatronic system. Moreover, the terminologies in the list can be extended by designers according to different design contexts.

It can be very complicated to select one suitable component from a set of alternatives, where multiple objectives are important to designers. The proposed component selection method provides designers with effective support to solve this MADM problem. The criteria for aiding designers in evaluating the alternatives and their combinations are proposed based on the non-functional requirements.

The proposed component selection method can generally be divided into two steps: component alternative pre-selection and architecture definition. In the component alternative pre-selection step, designers analyse the compatibility of the possible alternatives of two components linked by one interface, to eliminate impossible combinations of certain alternatives. The second step is known as “architecture definition”, in which designers select the optimal combination from the possible combinations by solving the MADM problem. The following sub-section presents the first step relating to the component alternative pre-selection.

3.2.2 Alternative pre-selection

If a mechatronic system can finally be decomposed into $M$ components $C^{m}$ ( $m=1,2,3,\ldots,M$ ), and the $m^{\text{th}}$ component can have $m_{N}$ alternatives, the $m_{n}^{\text{th}}$ alternative of the $m^{\text{th}}$ component can be denoted by $C_{m_{n}}^{m}$ ( $n=1,2,3,\ldots,m_{N}$ ). If all combinations of alternatives for each component are considered, designers will have $\prod_{i=1_{N}}^{M_{N}}i$ different types of combinations. A tremendous amount of work will be required to evaluate each combination and select the most suitable one. Therefore, the alternative pre-selection step is proposed to eliminate incompatible combinations of certain alternatives, which can significantly reduce the number of combinations, particularly for large and complex mechatronic systems. In this step, the non-functional requirement “Compatibility” should be considered.

It is known that one combination $\textit{COM}_{i}$ ( $i=1,\linebreak 2,\ldots,I$ ) can be determined by selecting the alternative $C_{m_{n}}^{m}$ for the component $C^{m}$ ( $m=1,2,3,\ldots,M;n=1,2,3,\ldots,m_{N}$ ). The 0–1 integer variable is introduced here to represent the combination $\textit{COM}_{i}$ .

$\displaystyle x_{m_{n}}^{m^{(i)}}=\left\{{\begin{array}[]{l}1\ldots\textit{% Alternative }C_{m_{n}}^{m}\textit{ is}\\ \textit{selected for component }C^{m}\textit{ of}\\ \textit{combination COM}_{i}\\ 0\ldots\textit{Alternative }C_{m_{n}}^{m}\textit{ is not}\\ \textit{selected for component }C^{m}\textit{ of}\\ \textit{combination COM}_{i}\\ \end{array}}\right.,$ (1)

where $m=1,2,3,\ldots,M;n=1,2,3,\ldots,m_{N};i=1,2,3,\ldots,I$ .

There must exist one and only one alternative for each component selected by designers; therefore, the following constraint should be satisfied:

$\displaystyle\sum\limits_{n=1}^{m_{N}}x_{m_{n}}^{m^{(i)}}=1,$ (2)

where $m=1,2,3,\ldots,M$ ; $i=1,2,3,\ldots,I$ .

Figure 3.

Example of alternative pre-selection step.

Interfaces can aid designers in guaranteeing the compatibility of different components. If two components can be integrated correctly by means of an interface, the pair of components is compatible [45]. As illustrated in Fig. 3, $C^{1}$ and $C^{2}$ are two components linked by an interface of a mechatronic system, and $C_{1}^{1}$ , $C_{2}^{1}$ , $C_{3}^{1}$ , and $C_{4}^{1}$ are the four possible alternatives to component $C^{1}$ , and $C_{1}^{2}$ and $C_{2}^{2}$ are the two possible alternatives to component $C^{2}$ . However, if the alternatives $C_{1}^{1}$ can only be linked to $C_{1}^{2}$ , the combinations of $C_{1}^{2}$ and $C_{2}^{1}$ , $C_{3}^{1}$ or $C_{4}^{1}$ do not exist. This alternative pre-selection step can be represented by the following equations.

$\displaystyle x_{1}^{1^{(i)}}=x_{1}^{2^{(i)}},$ (3) $\displaystyle 1-x_{1}^{2^{(i)}}=(1-x_{2}^{1^{(i)}})(1-x_{3}^{1^{(i)}})(1-x_{4}% ^{1^{(i)}})$ $\displaystyle\quad(i=1,2,3,\ldots I),$ (4)

Two components are considered to be incompatible with one another if they cannot be linked together directly or cannot be selected at the same time (examples regarding the incompatibility of different components can be found in Section 4.4).

The authors propose a compatibility indicator $Cp_{m_{i}n_{j}}$ with a value of 1 or 0 to denote that the alternatives (that is, $C_{i}^{m}$ and $C_{j}^{n}$ ) of two components (that is, $C^{m}$ and $C^{n}$ ) are compatible or incompatible with one another. Obviously, for a given combination of certain alternatives, if a pair of incompatible components exists, such a combination is invalid. In the pre-selection step, the compatibility indicator is adopted as a compatibility checking reference to aid designers in eliminating invalid combinations.

For a mechatronic system with $M$ components, all the component alternatives are involved in the pairwise checking. For the pairs formed from alternatives of the same component, the compatibility values are “0”, as there is no interface to connect them:

$\displaystyle Cp_{m_{i}m_{j}}=0,$ (5)

where $m=1,2,\ldots,M;i=1,2,\ldots,m_{N};j=1,\linebreak 2,\ldots,m_{N}$ .

For a pair formed by the alternatives of two different components, the related indicator value depends on whether or not the two components are compatible with one another. These values can be obtained by using the compatibility rules established by pre-defined knowledge or designers. For details on the compatibility rules and their implementation in computer-aided design platforms, interested readers are referred to [45].

To verify whether or not a combination with $M$ alternatives is valid, an algorithm is presented with the following pseudo-code.

Require: Return a value with name $V$ , by which designers can select valid combinations and eliminate invalid ones function comSelect () { $V=1$ ; for every value of $Cp_{m_{i}n_{j}}$ between the alternatives of components selected by designers do

$\displaystyle V=V\ast Cp_{m_{i}n_{j}}$

end for return $V$ }

Hence, any given combination can be checked via the value of $V$ .

$\displaystyle V=\left\{{\begin{array}[]{l}1\ldots\textit{the combination is % valid}\\ 0\ldots\textit{the combination is invalid}\\ \end{array}}\right.,$ (6)

For a system with small or medium-sized alternative combinations, all valid alternatives can be checked. When facing large-sized alternative combinations, this checking method can be embedded into an optimisation process to exclude invalid or “sub-optimal” alternatives; for example, by being embedded into the “generate-and-select” optimisation process [46].

With the aid of the alternative pre-selection step, the number of combinations that should be evaluated in the following step will be significantly decreased.

3.2.3 Architecture definition

Selecting the components among various alternatives to achieve the most suitable combination can be considered as a typical MADM problem [47]. Various methods, such as ranking methods (for example, the analytic hierarchy process (AHP) [48] and fuzzy methods [49]), and mathematical optimisation methods [50], have been proposed to solve the MADM problem. Ranking methods can order alternatives from best to worst with user preferences. Users can modify their requirements to adjust the order, which is more useful in practice because the success rate for selecting the optimal alternative can be improved. In the mathematical optimisation methods, objective functions are constructed to represent different factors or attributes, along with their interrelationships. Researchers aim to determine a set of ideal optimal solutions among the infinite solution space in theory when facing MADM problems [51]. The main difficulty within mathematical optimisation methods is the construction of suitable objective functions, as it is difficult to define or express the attributes and their interrelationships using accurate mathematical models, particularly for discrete variables.

Normally, non-functional requirements are used to test whether a product satisfies customer needs following the design phase. In this paper, the non-functional requirements are considered in the early design phase of a mechatronic system, so that design errors owing to ignorance of the requirements relating to the following processes can be avoided.

Following the pre-selection step, valid combinations can be obtained. Criteria for evaluating each combination are proposed by designers, according to the non-functional requirements. To evaluate these alternatives, a MADM model [52] is adopted. This model is composed of two sub-models, namely a deviation model and a similarity model. Hence, it includes two metrics for evaluation compared to other mono-metric models using “distance-based” evaluation. A further advantage of this model is that it is more suitable for dealing with vector-represented solutions in the discretised solution space. In this study, possible combinations can be represented by vectors with qualitative or quantitative values of the evaluation criteria; that is, non-functional requirements. The MADM model is expressed as follows:

$\displaystyle C^{*}=\mu C^{d}+(1-\mu)\varepsilon,$ (7)

where $C^{*}\in(0,1]$ represents the general index value of an alternative solution, $C^{d}$ represents the deviation extent and $\varepsilon$ represents the Grey similarity of an alternative to an ideal/aspired solution. Moreover, $\mu$ is a coefficient for adjusting the proportion of the indicator value, composed of two evaluation metric values. The ideal or aspired solution (known as the “goal solution/vector”) is composed of the best values (known or unknown) of each evaluation criterion. The solution may not exist in reality owing to conflicts among different criteria. However, it can be used to measure the differences among alternatives. For a given alternative vector and preferred goal vector,

$\displaystyle V^{a}=(A_{1}^{a},A_{2}^{a},A_{3}^{a},\ldots,A_{n}^{a})$ (8) $\displaystyle V^{g}=(A_{1}^{g},A_{2}^{g},A_{3}^{g},\ldots,A_{n}^{g}),$ (9)

where $V^{a}$ and $V^{g}$ denote the alternative and goal vectors, respectively; while $A_{i}^{a}$ and $A_{i}^{g}$ denote the $i^{\text{th}}$ attributes of the alternative and goal vectors, $i=(1,2,\linebreak 3\ldots n)$ . Then, the deviation index value, $C^{d}$ can be obtained by applying

$\displaystyle C^{d}=1/\sum\limits_{e^{i=1}}^{n}{\omega_{i}D_{i}}=1/\sum\limits% _{e^{i=1}}^{n}{\omega_{i}}\left|{{A_{i}^{a}-A_{i}^{g}}/{A_{i}^{g}}}\right|% \times 100\%,$ (10)

where $\omega_{i}$ is the $i^{\text{th}}$ attribute weight, $\omega_{i}\in W$ , $W=(\omega_{1},\omega_{2},\omega_{3},\ldots,\omega_{n})$ , and $D_{i}$ is the $i^{\text{th}}$ attribute deviation extent.

The similarity model is based on Grey incidence analysis, which can measure the similarity between two data sequences to determine whether or not their relation is close by investigating their “shapes”, but not “distance”. Therefore, Grey incidence analysis is highly suitable for compensating for the drawback of the “distance-based” model, by measuring the similarity of curves/datasets in the $n$ -dimensional solution space or mapped onto the two-dimensional parallel coordinate system. For two given vectors with $n$ attributes,

$\displaystyle V_{i}=\left({\chi_{i}(1),\chi_{i}(2),\chi_{i}(3),\ldots,\chi_{i}% (n)}\right)$ (11) $\displaystyle V_{j}=\left({\chi_{j}(1),\chi_{j}(2),\chi_{j}(3),\ldots,\chi_{j}% (n)}\right),$ (12)

and their processed forms (processed by Grey operators),

$\displaystyle V_{i}^{0}=\left({\chi_{i}^{0}(1),\chi_{i}^{0}(2),\chi_{i}^{0}(3)% ,\ldots,\chi_{i}^{0}(n)}\right)$ (13) $\displaystyle V_{j}^{0}=\left({\chi_{j}^{0}(1),\chi_{j}^{0}(2),\chi_{j}^{0}(3)% ,\ldots,\chi_{j}^{0}(n)}\right).$ (14)

The similarity between the two vectors can be obtained by applying:

$\displaystyle\varepsilon_{ij}=(1+\left|{s_{i}}\right|+\left|{s_{j}}\right|)/(1% +\left|{s_{i}}\right|+\left|{s_{j}}\right|+\left|{s_{i}-s_{j}}\right|),$ (15)

where $\varepsilon_{ij}$ denotes the Grey incidence between the two vectors,

$\displaystyle s_{i}=\left|{\sum\limits_{k=2}^{n-1}{\chi_{i}^{0}(k)+\textstyle{% 1\over 2}\chi_{i}^{0}(n)}}\right|$ (16) $\displaystyle s_{j}=\left|{\sum\limits_{k=2}^{n-1}{\chi_{j}^{0}(k)+\textstyle{% 1\over 2}\chi_{j}^{0}(n)}}\right|$ (17) $\displaystyle\left|{s_{i}-s_{j}}\right|=\left|\sum\limits_{k=2}^{n-1}(\chi_{i}% ^{0}(k)-\chi_{j}^{0}(k))\right.$ (18) $\displaystyle\quad+\left.\frac{1}{2}(\chi_{i}^{0}(n)-\chi_{j}^{0}(n))\right|.$

The similarity obtained by applying Eq. (15) is known as the absolute degree of Grey incidence, which can measure the similarity for vectors with more than two attributes. For those vectors with two attributes, the relative degree of Grey incidence can be adopted to measure the similarity. The relative degree of Grey incidence is used to calculate the value change rate of the second attribute compared to the first one in a vector or data sequence with two attributes. If the change rates of the two vectors are more similar, the similarity between them is greater. The calculation of the relative degree of Grey incidence is similar to the calculation of the absolute degree of Grey incidence, but the original vectors are processed by different Grey operators. Further details regarding the Grey operations can be found in [53].

Figure 4.

UML activity diagram for architecture definition process.

With the above adopted MADM model, to use multiple non-functional requirements for evaluating the combinations of the component alternatives, the requirement-driven architecture definition approach is complete. Figure 4 represents the general procedure for this approach with a UML activity diagram. The design requirements should firstly be classified into functional and non-functional requirements. The functional requirements provide initial information regarding the main architecture. Following the component and interface decomposition process, the discipline-specific components of the system and their alternatives can eventually be achieved. Criteria for evaluating the alternatives and their combinations can be proposed according to the non-functional requirements. Following the application of the compatibility checking method in the alternative pre-selection step, designers can select the most suitable combination from the possible combinations by using the MADM model.

4. Case studies

Two case studies, corresponding to the designs of a lunar roving vehicle and an automated CMC materials cutting system, are presented in this section to demonstrate the application of the requirement-driven architecture definition approach to systems engineering practices, in both the academic and industrial domains.

Table 1
Functional requirements for lunar roving vehicle

Functional requirement
FR ${}^{1}$ : The vehicle should move and stop automatically.
FR ${}^{1.1}$ : The vehicle should be started by the operator.
FR ${}^{1.2}$ : The vehicle should detect the black bands.
FR ${}^{1.3}$ : The vehicle should stop and send a beep when the base camp is reached.
FR ${}^{1.4}$ : Power should be supplied to the vehicle.
FR ${}^{2}$ : The vehicle should detect the environment.
FR ${}^{2.1}$ : The vehicle should record a video of the environment.
FR ${}^{2.2}$ : The video should be transmitted to the control centre in real time.
FR ${}^{2.3}$ : The video should be displayed on the remote control terminal.
FR ${}^{3}$ : The vehicle should place waypoints on different points.
FR ${}^{3.1}$ : The operator should control the vehicle to place the waypoints.
FR ${}^{3.2}$ : The operator should control the vehicle to move among the different points.

4.1 Lunar roving vehicle

The first case study is a lunar roving vehicle for the RobAFIS robot competition, organised by the French chapter of the International Council on Systems. The requirements demanded by the RobAFIS robot competition are presented hereafter.

4.1.1 Presentation of requirements for lunar roving vehicle

The RobAFIS is a robot competition organised by the French chapter of the International Council on Systems, the main objective of which is to highlight the benefits of basic systems engineering education in the development of complex systems in a real environment. An official document is distributed to each team, consisting of students and their supervising teachers. They should realise a collaborative systems engineering approach to develop a robot, satisfying certain requirements described in the official document.

According to the official document of RobAFIS 2016, each team is required to develop a lunar roving vehicle based on LEGO Mindstorm EV3. The lunar roving vehicle is controlled by a single operator from the control centre on earth, which does not have a direct view of the vehicle in its deployment area on the moon. The lunar roving vehicle should fulfil one ex- ploration mission on the moon.

The exploration mission is divided into three phases. During the first phase, moving the lunar roving vehicle from the arrival area to the base camp by following the black bands is carried out without operator intervention. When the base camp is reached, the vehicle automatically stops and sends a beep to indicate that the following step can be engaged.

The operator engages the second phase by taking control of the vehicle, from the control centre and through the remote control terminal. To track its movements and identify the area and waypoints, the operator has a video feedback, provided by a camera mounted on the vehicle, and the video is transmitted to the control centre and displayed on the remote control terminal. The global mission will involve placing the waypoints (identification marks) on different points of the planet surface considered as dangerous, to allow the vehicles of following missions to move securely.

The global mission will take place over three days, with different waypoints for each day:

•
one slot on the first day;
•
two low light areas on the second day; and
•
three bad linking conditions with the control centre on the third day.

The third phase decomposes the vehicle joining the base camp, and then the arrival area at the end of the day. During this phase, the waypoints should be completed; the vehicle should be manually controlled by the operator from the control centre via the remote control terminal.

In addition to the missions that should be fulfilled by the lunar roving vehicle, other constraints such as the dimension, weight, and development leading time, are also demanded in the official document of RobAFIS 2016.

The following sub-section presents the specification of functional and non-functional requirements according to the previous introduction to the lunar roving vehicle.
4.1.2 Specification of functional and non-functional requirements

After analysing the official document of the lunar roving vehicle, designers should specify the requirements and classify them as functional and non-functional requirements.

As discussed in Section 3, functional requirements define the system behaviour and they can be further decomposed into sub-functional requirements. Table 1 displays the hierarchical structure of the functional requirements for the lunar roving vehicle.

The authors propose a list of non-functional requirements for the design of mechatronic systems. According to the description in the official document of RobAFIS 2016, several criteria can be selected from the list of non-functional requirements (Table 2).

Table 2
Non-functional requirements for lunar roving vehicle

Description in official document of RobAFIS 2016	Non-functional requirement
	(criterion)
The development leading time should not exceed two months.	$\textit{Cr}_{1}$ : Development leading time
The cost for the development should be affordable for the team.	$\textit{Cr}_{2}$ : Affordability
The maximum dimension of the vehicle should not exceed 300 mm $\times$ 250 mm and a height of 250 mm.	$\textit{Cr}_{3}$ : Physical Size
The maximum mass of the vehicle in operation should not exceed 1.5 kg.	$\textit{Cr}_{4}$ : Weight
The integration and verification should not exceed 15 minutes.	$\textit{Cr}_{5}$ : Simplicity
The standard time for completing the mission should not exceed five minutes.	$\textit{Cr}_{6}$ : Efficiency
The technical assistant should not intervene in the vehicle during the mission.	$\textit{Cr}_{7}$ : Robustness

In the requirement-driven architecture definition approach, the functional requirements aid designers in realising the system decomposition, while the non-functional requirements enable designers to solve the component selection problem. The following sub-section presents the system decomposition process for the lunar roving vehicle using the specification results of the functional requirements.

Figure 5.

Functional requirements, functional structure and main sub-systems.

4.1.3 System decomposition for lunar roving vehicle

When the functional requirement specification is completed, a hierarchical functional structure can be defined, and the principal sub-systems of the lunar roving vehicle exhibiting the sub-functions can be proposed (Fig. 5).

The eight main sub-systems should be further decomposed to achieve the complete architecture. For example, the remote control sub-system ( $C^{1}$ ), movement sub-system ( $C^{3}$ ), and waypoint placement sub-system ( $C^{7}$ ) should be further decomposed. The movement sub-system, for example, can be further broken down into the LEGO EV3 programmable brick ( $C^{3.1}$ ), motors ( $C^{3.2}$ ), and chassis ( $C^{3.3}$ ). However, according to the component decomposition method, it is not necessary to decompose all sub-systems further into components; for example, the colour sensor ( $C^{2}$ ), power supply ( $C^{4}$ ), camera ( $C^{5}$ ), and video transmission ( $C^{6}$ ), because some of these can be considered as standard components (such as $C^{2}$ , $C^{5}$ , and $C^{6}$ ), and the power supply can be designed by the electrical design team. Figure 6 illustrates the system decomposition for the lunar roving vehicle.

Figure 6.

System decomposition for lunar roving vehicle.

After applying the proposed system decomposition method, the lunar roving vehicle is decomposed into components. However, different component candidates or design solutions may be proposed for each component by discipline-specific design teams. The following sub-section presents the component selection process for the lunar roving vehicle.

4.1.4 Component selection for lunar roving vehicle

Table 3 displays the component candidates or design solutions for each component of the lunar roving vehicle, which can be considered as design alternatives, and the most suitable combination among these should be selected.

Table 3
Components and their alternatives

Component	Alternative
$C^{1.1}$	$C_{1}^{1.1}$ : PC screen
$C^{1.2}$	$C_{1}^{1.2}$ : GUI (keyboard and mouse control)
	$C_{2}^{1.2}$ : GUI (joystick control)
$C^{1.3}$	$C_{1}^{1.3}$ : Bluetooth
$C^{2}$	$C_{1}^{2}$ : Colour sensor
$C^{3.1}(C^{7.1})$	$C_{1}^{3.1}(C_{1}^{7.1})$ : LEGO EV3 programmable brick
$C^{3.2}$	$C_{1}^{3.2}$ : Motors
$C^{3.3}$	$C_{1}^{3.3}$ : Chassis (4 wheels)
	$C_{2}^{3.3}$ : Chassis (2 wheels and 1 metal ball)
	$C_{3}^{3.3}$ : Chassis (2 tracks)
$C^{4}$	$C_{1}^{4}$ : Power supply
$C^{5}$	$C_{1}^{5}$ : Smartphone
	$C_{2}^{5}$ : Webcam
	$C_{3}^{5}$ : Raspberry PI
$C^{6}$	$C_{1}^{6}$ : Ethernet cable
	$C_{2}^{6}$ : WiFi
$C^{7.2}$	$C_{1}^{7.2}$ : Motors
$C^{7.3}$	$C_{1}^{7.3}$ : Mechanical part (belt conveyor)
	$C_{2}^{7.3}$ : Mechanical part (lead screw)

If all alternative combinations for each component are considered, designers will have 72 different combinations. However, the step of “alternative pre-selection” can be adopted to eliminate invalid combinations of certain alternatives, which can significantly reduce the number of combinations.

In this step, the non-functional requirement “Compatibility” should be taken into consideration. After analysing the compatibility between the proposed alternatives for each component, designers find that the smartphone ( $C_{1}^{5}$ ) or Raspberry PI ( $C_{3}^{5}$ ) cannot connect to the Ethernet cable ( $C_{1}^{6}$ ). Therefore, combinations that include $C_{1}^{5}$ and $C_{1}^{6}$ or $C_{3}^{5}$ and $C_{1}^{6}$ are invalid. Moreover, if designers adopt the “belt conveyor” solution ( $C_{1}^{7.3}$ ) for the mechanical part, the chassis with two tracks ( $C_{3}^{3.3}$ ) cannot be selected, because the LEGO pack EV3 provides designers with only two tracks. If one track is used to construct the belt conveyor, designers cannot use only one track to construct the two-track chassis; thus, combinations including $C_{1}^{7.3}$ and $C_{3}^{3.3}$ should be eliminated. Based on the aforementioned compatibility knowledge, a matrix can be used to record the compatibility indicator values. Table 4 presents part of the compatibility matrix.

Thereafter, according to the algorithm for alternative pre-selection, presented in Section 3.3.2, the combinations with “0” values of $V$ are identified as invalid, as they include incompatible components.

After eliminating such invalid combinations, the number of possible combinations is reduced to 36. In the following stage, the designers need to identify the most suitable combination from these valid alternatives. To evaluate the alternatives, decision criteria and weights should be set. In this case study, seven non-functional requirements are selected, according to the description in the official document of RobAFIS 2016. These non-functional requirements can be used as evaluation criteria.

Table 4

Compatibility matrix for lunar roving vehicle

	$C_{1}^{1.1}$	…	$C_{3}^{3.3}$	$C_{1}^{4}$	$C_{1}^{5}$	$C_{2}^{5}$	$C_{3}^{5}$	$C_{1}^{6}$	$C_{2}^{6}$	$C_{1}^{7.2}$	$C_{1}^{7.3}$	$C_{2}^{7.3}$
$C_{1}^{1.1}$	0	…	1	1	1	1	1	1	1	1	1	1
…		0	1	1	1	1	1	1	1	1	1	1
$C_{3}^{3.3}$			0	1	1	1	1	1	1	1	0	1
$C_{1}^{4}$				0	1	1	1	1	1	1	1	1
$C_{1}^{5}$					0	0	0	0	1	1	1	1
$C_{2}^{5}$						0	0	1	1	1	1	1
$C_{3}^{5}$							0	0	1	1	0	1
$C_{1}^{6}$								0	0	1	1	1
$C_{2}^{6}$									0	1	1	1
$C_{1}^{7.2}$										0	1	1
$C_{1}^{7.3}$											0	0
$C_{2}^{7.3}$												0

Table 5

Criteria values of each alternative for lunar roving vehicle

		$\textit{Cr}_{1}$	$\textit{Cr}_{2}$	$\textit{Cr}_{3}$	$\textit{Cr}_{4}$	$\textit{Cr}_{5}$	$\textit{Cr}_{6}$	$\textit{Cr}_{7}$
$C^{1.2}$	$C_{1}^{1.2}$	3 days	30€	Null	Null	2 min	7	7
	$C_{2}^{1.2}$	6 days	60€	Null	Null	4 min	3	5
$C^{3.3}$	$C_{1}^{3.3}$	0.5 days	Null	250 mm $\times$ 200 mm $\times$ 50 mm	250 g	1 min	5	5
	$C_{2}^{3.3}$	0.5 days	Null	250 mm $\times$ 200 mm $\times$ 50 mm	200 g	1 min	7	7
	$C_{3}^{3.3}$	0.5 days	Null	250 mm $\times$ 200 mm $\times$ 60 mm	310 g	1 min	3	3
$C^{5}$	$C_{1}^{5}$	1 day	300€	120 mm $\times$ 60 mm $\times$ 10 mm	120 g	2 min	7	7
	$C_{2}^{5}$	1.5 days	60€	80 mm $\times$ 40 mm $\times$ 40 mm	100 g	3 min	5	5
	$C_{3}^{5}$	2 days	45€	100 mm $\times$ 60 mm $\times$ 15 mm	50 g	4 min	5	5
C ${}^{6}$	$C_{1}^{6}$	0.5 days	Null	Null	Null	4 min	7	5
	$C_{2}^{6}$	0.5 days	Null	Null	Null	1 min	5	7
$C^{7.3}$	$C_{1}^{7.3}$	0.5 days	Null	50 mm $\times$ 30 mm $\times$ 30 mm	50 g	1 min	7	7
	$C_{2}^{7.3}$	0.5 days	Null	60 mm $\times$ 35 mm $\times$ 35 mm	60 g	1 min	3	5

Table 5 presents the criteria values of each alternative. The values are determined according to the following principles:

•

The estimation and determination of the criteria values for each alternative is a complicated process. The team of the Université de Technologie de Compiègne (UTC) has participated in the RobAFIS robot competition several times; thus, the proposed alternatives for each component have been tested during the competitions in previous years. For example, the joystick was tested and adopted in the remote control sub-system for RobAFIS 2015. Therefore, its development leading time, cost, and other factors, were estimated using historical projects.

•

For the values that can be quantified (such as development leading time, cost, and physical size), designers can directly provide their estimations. However, for qualitative values (such as efficiency and robustness), a five-level scoring system is used to indicate their grades. Table 6 displays the relationships between the scores and grades.

Table 6

Variables for quality grades of alternatives

Quality grades	Scores
Very low	1
Low	3
Neutral	5
High	7
Very high	9

•

Not all alternatives should be evaluated by every criterion. This principle can be applied to two cases. The first case is that, although certain criteria can be proposed for certain components, designers select the suitable components with little aid from such criteria. For example, it is unnecessary to consider the cost of chassis assembled by the pieces of LEGO pack EV3, because the LEGO pack EV3 is provided by the competition organisers and a criterion such as Affordability ( $\textit{Cr}_{2}$ ) cannot aid designers in making a useful decision on the chassis selection, even though the chassis cost can be estimated. The second case concerns the criteria that are meaningless for certain components. For example, evaluation of the video transmission solution (Ethernet cable or WiFi) by the criteria Physical size ( $\textit{Cr}_{3}$ ) and Weight ( $\textit{Cr}_{4}$ ) is meaningless for designers. Hence, values that are not considered or meaningless are regarded as “null” in the following evaluation computation. For components with no alternatives, such as the colour sensor ( $C_{1}^{2}$ ), their values are also not considered in the evaluation, as all of the alternative combinations use those components and they make no difference in the evaluation.

In multi-criteria decision-making, usually, not all criteria have the same importance. It is necessary to assign decision weights to different decision criteria to express the design requirements more effectively.

Table 7

Example of evaluation results of alternative design combinations

Alternatives	$C^{d}$	$\varepsilon$	$C^{*}$
$V_{a}$ (1): ( $C_{1}^{1.1},C_{1}^{1.2},C_{1}^{2},C_{1}^{3.1},C_{1}^{3.2},C_{1}^{3.3},C_{1}^{4% },C_{1}^{5},C_{2}^{6},C_{1}^{7.2},C_{1}^{7.3})$	0.0188	0.9455	0.4822
$V_{a}$ (2): ( $C_{1}^{1.1},C_{2}^{1.2},C_{1}^{2},C_{1}^{3.1},C_{1}^{3.2},C_{1}^{3.3},C_{1}^{4% },C_{3}^{5},C_{2}^{6},C_{1}^{7.2},C_{1}^{7.3})$	0.0974	0.9892	0.5433
$V_{a}$ (3): ( $C_{1}^{1.1},C_{1}^{1.2},C_{1}^{2},C_{1}^{3.1},C_{1}^{3.2},C_{2}^{3.3},C_{1}^{4% },C_{1}^{5},C_{2}^{6},C_{1}^{7.2},C_{1}^{7.3})$	0.0250	0.9517	0.4883
$V_{a}$ (4): ( $C_{1}^{1.1},C_{2}^{1.2},C_{1}^{2},C_{1}^{3.1},C_{1}^{3.2},C_{2}^{3.3},C_{1}^{4% },C_{1}^{5},C_{2}^{6},C_{1}^{7.2},C_{1}^{7.3})$	0.0061	0.9503	0.4782
$V_{a}$ (5): ( $C_{1}^{1.1}$ , $C_{1}^{1.2}$ , $C_{1}^{2}$ , $C_{1}^{3.1}$ , $C_{1}^{3.2}$ , $C_{2}^{3.3}$ , $C_{1}^{4}$ , $C_{3}^{5}$ , $C_{2}^{6}$ , $C_{1}^{7.2}$ , $C_{1}^{7.3}$ )	0.5242	0.9984	0.7613
$V_{a}$ (6): ( $C_{1}^{1.1},C_{1}^{1.2},C_{1}^{2},C_{1}^{3.1},C_{1}^{3.2},C_{1}^{3.3},C_{1}^{4% },C_{1}^{5},C_{2}^{6},C_{1}^{7.2},C_{2}^{7.3})$	0.0152	0.9411	0.4781
…			…

Note: the best alternative is that with the largest index value, $C^{*}$ . In this table, only six out of 36 alternatives are presented.

In the case study, the competition rules described in the official document imply the weight of each criterion. For example, in accordance with the competition rules, the lunar roving vehicle with a maximum dimension exceeding 300 mm $\times$ 250 mm and a height of 250 mm is not allowed to participate in the competition ( $\textit{Cr}_{3}$ ); the penalty for intervention of the technical assistant is 2 points ( $\textit{Cr}_{7}$ ), and the penalty for timeout (that is, the mission is not completed in five minutes) is 10 points ( $\textit{Cr}_{6}$ ). Therefore, the order of the weights for $\textit{Cr}_{3}$ , $\textit{Cr}_{6}$ , and $\textit{Cr}_{7}$ can be described as:

$\displaystyle\omega_{3}>\omega_{6}>\omega_{7}.$

For other criteria, even decision weights are assigned. Hence, the weights for the selected decision criteria are expressed as

$\displaystyle W=(\omega_{1},\omega_{2},\omega_{3},\omega_{4},\omega_{5},\omega% _{6},\omega_{7})=(0.10,0.10,0.25,0.10,0.10,0.20,0.15).$

When the decision criteria values and weights have been established, the next step is to apply the adopted MADM model introduced in Section 3 to generate decision index values for ranking the alternative design combinations. For computation, all alternatives should be represented by criteria vectors and an ideal or aspired solution (known as the “goal solution/vector”), and the ideal/aspired design combination should be constructed. For example, an alternative combination

$\displaystyle(C_{1}^{1.1},C_{1}^{1.2},C_{1}^{2},C_{1}^{3.1},C_{1}^{3.2},C_{1}^% {3.3},C_{1}^{4},C_{1}^{5},C_{2}^{6},$ $\displaystyle C_{1}^{7.2},C_{1}^{7.3})$

can be represented by an equivalent simplified vector with seven evaluation criteria values, as follows:

$\displaystyle V_{a}=(Cr_{1}^{a},Cr_{2}^{a},Cr_{3}^{a},Cr_{4}^{a},Cr_{5}^{a},Cr% _{6}^{a},Cr_{7}^{a}).$

Similarly, the “goal solution/vector” can also be represented by a vector composed of seven criteria with their best values:

$\displaystyle V_{g}=(\textit{Cr}_{1}^{g},\textit{Cr}_{2}^{g},\textit{Cr}_{3}^{% g},\textit{Cr}_{4}^{g},\textit{Cr}_{5}^{g},\textit{Cr}_{6}^{g},\textit{Cr}_{7}% ^{g}),$

where $\textit{Cr}_{i}^{g}$ is the best value of the $i^{\text{th}}$ criterion. For example, the best value of $\textit{Cr}_{1}$ , leading time, should be the minimum total leading time, namely 5.5 days, of a combination. Sometimes, a combination with a minimum criteria value is invalid, but its value can also be used to build the “goal solution/vector”, as the “goal solution/vector” is only used as a target in the evaluation process for measuring the distance or similarity difference. With the values in Table 5, the element values of the “goal solution/vector” can be obtained as follows:

$\displaystyle V_{g}=(\textit{Cr}_{1}^{g},\textit{Cr}_{2}^{g},\textit{Cr}_{3}^{% g},\textit{Cr}_{4}^{g},\textit{Cr}_{5}^{g},\textit{Cr}_{6}^{g},\textit{Cr}_{7}% ^{g})=(5.5/\text{days},75/\text{euros},2671/\text{cm}^{3},300/\text{g},7/\text% {min},35,35)$

With the “goal solution/vector” and alternative vectors, index values for decision-making can be calculated by applying Eqs (10) and (15). Table 7 provides several evaluation results of the 36 valid alternative design combinations. The alternative with the largest index value, 0.7613, is identified as the optimal alternative.

Therefore, the optimal design combination is:

$\displaystyle(C_{1}^{1.1},C_{1}^{1.2},C_{1}^{2},C_{1}^{3.1},C_{1}^{3.2},C_{2}^% {3.3},C_{1}^{4},C_{3}^{5},C_{2}^{6},$ $\displaystyle C_{1}^{7.2},C_{1}^{7.3})$

Figure 7 illustrates the lunar roving vehicle and its final component selection.

Figure 7.

Lunar roving vehicle and its component selection.

The applicability of the proposed design method is demonstrated by an academic example. However, for design cases in the industry, functional and non-functional requirements are seldom formalised in detail in an official document, and designers should capture both types of requirements from customers. However, the number of alternative combinations from which designers select the most suitable combination may be large owing to the tremendous number of components and their alternatives. An industrial case based on an automated CMC materials cutting system is selected to demonstrate the proposed design method in the following sub-section.

Table 8

Functional requirements for automated CMC materials cutting system

Functional requirement
Fr ${}^{1}$ : The system should be controlled.
Fr ${}^{1.1}$ : The system should be operated by operators.
Fr ${}^{1.2}$ : The system should provide operators with a human-machine interface (HMI).
Fr ${}^{1.3}$ : Power should be supplied to the system.
Fr ${}^{2}$ : The system should cut CMC workpieces into different forms according to CAD models automatically.
Fr ${}^{2.1}$ : The system should capture the initial position of the workpiece.
Fr ${}^{2.2}$ : The system program should be generated automatically.
Fr ${}^{2.3}$ : The system should move to the position set in the program.
Fr ${}^{2.4}$ : The cutting tools should be used for cutting CMC materials.
Fr ${}^{3}$ : System and operator safety should be guaranteed.
Fr ${}^{3.1}$ : The system should detect collisions between the robot with workpieces and the environment automatically.
Fr ${}^{3.2}$ : Operator safety should be guaranteed.

4.2 Automated CMC materials cutting system

The second case study selected for demonstrating the application of the proposed requirement-driven architecture definition approach is an industrial example. The team of the School of Mechanical Engineering at the Northwestern Polytechnical University (NPU) is required to design an automated CMC materials cutting system by a local superhard material company to cut workpieces made of CMC materials into various forms, according to different industrial uses. CMC material is a type of superhard material that is widely used in the components for high-temperature gas turbines, space vehicles, and brake systems, among others, because of its high hardness, reduced weight, and corrosion and high-temperature resistance.

4.2.1 Specification of functional and non-functional requirements

As opposed to the academic design example corresponding to the lunar roving vehicle in which customer needs have been described in detail in the official document, designers should capture the design requirements of the automated CMC materials cutting system from interviews with stakeholders and analyses of usage scenarios.

According to interviews with stakeholders and analysis results of usage scenarios, the authors summarise the hierarchical structure of the main functional requirements in Table 8. The criteria selected from the list of non-functional requirements to evaluate the alternative combinations for each component are presented in Table 9.

Table 9
Non-functional requirements for automated CMC materials cutting system

Interviews with stakeholders	Non-functional requirements
	(criteria)
The system should offer a high level of accuracy when cutting materials (the positioning accuracy should be higher than 0.03 mm).	$\textit{Cr}_{1}$ : Accuracy
The cost of the system should be affordable (the development cost should be less than 3,000,000 CNY (430,000 USD)).	$\textit{Cr}_{2}$ : Affordability
The duration between the placement of the contract and system delivery should be 2 years.	$\textit{Cr}_{3}$ : Development leading time
The system should not result in environmental pollution.	$\textit{Cr}_{4}$ : Environmental impact
The system should make future maintenance easier.	$\textit{Cr}_{5}$ : Maintainability
The system operation should be easy to learn for operators.	$\textit{Cr}_{6}$ : Operability
The maximum dimension of the system should not exceed 5 m $\times$ 5 m and a height of 3 m.	$\textit{Cr}_{7}$ : Physical size
The system should have a fast cutting process (the cutting speed should be higher than 3 m/min).	$\textit{Cr}_{8}$ : Productivity
The cutting process should not harm or change the intrinsic properties of the CMC materials.	$\textit{Cr}_{9}$ : Quality of products
The system should cope with errors during operation.	$\textit{Cr}_{10}$ : Robustness
The system should provide measures to ensure operator safety.	$\textit{Cr}_{11}$ : Safety

4.2.2 System decomposition for automated CMC materials cutting system

According to the proposed system decomposition method, the main sub-systems can be determined by embodying the functional requirements, and the components can be obtained by decomposing the proposed sub-systems. Figure 8 illustrates the components and the interfaces among them for the automated CMC materials cutting system.

Figure 8.

System decomposition for automated CMC materials cutting system.

4.2.3 Component selection for automated CMC materials cutting system

Table 10 presents the design alternatives for each component of the automated materials cutting system, from which the most suitable combination should be selected.

Table 10
Components and their alternatives

Component	Alternatives
$C^{1.1}$	$C_{1}^{1.1}$ : Programmable logic controller (PLC)
	$C_{2}^{1.}$ : Six-axis robot control
	$C_{3}^{1.1}$ : Cartesian coordinate robot control
$C^{1.2}$	$C_{1}^{1.2}$ : Laser cutting control system
	$C_{2}^{1.2}$ : Waterjet cutting control system
	$C_{3}^{1.2}$ : Polycrystalline diamond (PCD) cutting control system
$C^{1.3}$	$C_{1}^{1.3}$ : Gantry control
	$C_{2}^{1.3}$ : Automated guided vehicle (AGV) control
$C^{1.4}$	$C_{1}^{1.4}$ : Human-Machine Interface
$C^{1.5}$	$C_{1}^{1.5}$ : Linear fitting of workpiece edge
	$C_{2}^{1.5}$ : Shape reconstruction of pattern image
$C^{2.1}$	$C_{1}^{2.1}$ : Six-axis robot
	$C_{2}^{2.1}$ : Cartesian coordinate robot
$C^{2.2}$	$C_{1}^{2.2}$ : Gantry
	$C_{2}^{2.2}$ : AGV
$C^{2.3}$	$C_{1}^{2.3}$ : Light source & camera
	$C_{2}^{2.3}$ : Fringe pattern & camera
$C^{3}$	$C_{1}^{3}$ : On-line program
	$C_{2}^{3}$ : Off-line program
$C^{4}$	$C_{1}^{4}$ : Power supply sub-system
$C^{5.1}$	$C_{1}^{5.1}$ : Safety fence
$C^{5.2}$	$C_{1}^{5.2}$ : Sensor-based method
	$C_{2}^{5.2}$ : Collision detection algorithm (sensorless collision detection method)
	$C_{3}^{5.2}$ : Hybrid method (sensor and collision detection algorithm)
$C^{6}$	$C_{1}^{6}$ : Laser cutting tool
	$C_{2}^{6}$ : Waterjet cutting tool
	$C_{3}^{6}$ : PCD cutting tool

As opposed to the academic example, the number of alternative combinations from which designers select the most suitable is excessively large, owing to the tremendous number of components and their alternatives involved in industrial mechatronic systems. Therefore, compared to the academic example, designers should pay additional attention to the pre-selection step, during which impossible alternative combinations can be eliminated, so that the number of combinations evaluated during the architecture definition step can be significantly reduced. The alternative pre-selection algorithm presented in Section 3.2.3 aids designers in eliminating invalid combinations of certain alternatives, including incompatible components. In this case, for example, the six-axis robot ( $C_{1}^{2.1}$ ) can be controlled by the PLC ( $C_{1}^{1.1}$ ) or the six-axis robot controller ( $C_{2}^{1.1}$ ), but it cannot be controlled by the controller that is specially designed for the Cartesian coordinate robot ( $C_{3}^{1.1}$ ). After elimination of such invalid combinations by the proposed pre-selection algorithm, the number of possible combinations can be reduced from 5184 to 288 in this case study.

Finally, designers should select the most suitable option from the list of alternative combinations. Firstly, together with stakeholders, designers assign the decision weights to the proposed criteria to indicate the different importance values of the non-functional requirements. For example, the operator safety ( $\textit{Cr}_{11}$ ) should be considered as the most significant factor during the industrial manufacturing process. Moreover, even though the income of the company can be increased by improving productivity ( $\textit{Cr}_{8}$ ), the long-term revenue of the company is ensured by the quality of products ( $\textit{Cr}_{9}$ ). Therefore, the order of the weights for $\textit{Cr}_{8}$ , $\textit{Cr}_{9}$ , and $\textit{Cr}_{11}$ can be described as:

$\displaystyle\omega_{11}>\omega_{9}>\omega_{8}.$

After assigning the decision weights to different criteria, designers determine the values of the alternatives for each component. For example, compared to waterjet cutting, laser cutting has a narrower kerf width, so it can achieve higher accuracy. However, the laser cutting results in the heat-affected zone that may lead to a change in the intrinsic properties of the CMC materials. By using the proposed algorithm in Section 3.2.3 to solve such an MADM problem, designers can select the most suitable option from the list of alternative combinations.

Figure 9 illustrates the automated CMC materials cutting system and its final component selections.

Figure 9.

Automated CMC materials cutting system and its component selection.

5. Discussion

The proposed requirement-driven architecture definition approach is discussed in this paper. Based on the results of the requirement specifications, the proposed architecture definition approach provides the following advantages:

•
This paper adopts the classification method proposed by Roman, in which the requirements are classified into functional and non-functional requirements. The functional requirements aid designers in realising the system decomposition, while the non-functional requirements enable designers to solve the component selection problem.
•
A list of non-functional requirements regarding the specificities in the design of mechatronic systems is proposed to aid designers in selecting the criteria and the most suitable components. The proposed component selection method is divided into two steps: component alternative pre-selection and architecture definition. In the first step, designers analyse the compatibility for the possible alternatives of two components linked by one interface to eliminate impossible combinations of certain alternatives. In the second step, designers select the most suitable combination from the possible combinations by solving the MADM problem.

Nevertheless, although the design teams of UTC and NPU applied the proposed requirement-driven architecture definition approach successfully in both the academic and industrial domains, several perspectives for future research based on this approach are recommended, as follows:

•
In this paper, a lunar roving vehicle proposed by the RobAFIS robot competition is selected to demonstrate the requirement-driven architecture definition approach. Customer needs have been described in detail in the official document. Instead of capturing the requirements from customers, designers can obtain customer requirements for the lunar roving vehicle and classify these into functional and non-functional requirements by carefully analysing the official document. However, in most industrial design cases, such as the case study of the automated CMC materials cutting system, the manner in which to capture the design requirements, particularly the informal or potential requirements, from stakeholders and usage scenarios, remains a critical issue for designers. In Section 2, several methods for the capturing of design requirements have been reviewed, and these can be considered as potential solutions to the problems relating to capturing design requirements. However, products have become increasingly complex, and obtaining comprehensive customer requirements becomes more challenging. Substantially more attention should be paid to the method for capturing the design requirements of complex systems from stakeholders and usage scenarios in the future.
•
Without using any optimisation searching scheme, the number of combinations that should be evaluated in the following step for the two cases above have even been considerably decreased. However, for other more complex design problems, in which the supply chain is longer or supplier network is wider and more candidate components are available, the complexity scale of the pre-selection and evaluation will be quite high. For such a complex design context, various mathematical optimisation algorithms and methods applied in other domains could be used to aid designers in finding a set of ideal optimal solutions among the huge or even infinite solution space [54]. For example, Kyriklidis and Dounias adopted the genetic algorithm to find the most optimal manner to allocate resources for project management [55]. Mencia et al. used the genetic algorithm to achieve the best solution for the scheduling problem during the production process [56]. Wang and Szeto adopted the chemical reaction optimisation algorithm to determine the optimal solution for transportation network design [57]. These algorithms could possibly be modified with special encoding to represent alternative combinations in a discrete manner for the design problem in this study. Thereafter, a type of searching scheme could be applied to explore the large solution space. As mentioned previously, when the number of alternative solutions is huge, the adopted decision-making model can be embedded into the search scheme as a main objective or fitness function to improve the searching and decision-making efficiency for the optimisation process.
•
For the cases in this study, the design-related datasets are managed either manually or by “raw” algorithms, without a friendly user interface “package”. In practice, it is necessary to provide the IT integration of software for managing the design data, thereby ensuring access exclusively to authorised designers and avoiding malicious ones [58]. Therefore, future work should focus on the implementation of the proposed requirement-driven architecture definition approach in a home-made expert PLM system. Knowledge-based engineering (KBE) methods and tools will be adopted for the expert system development. Moreover, design rules or case families [59] will be structured. Therefore, case-based reasoning (CBR) [60] or rule-based reasoning [61] can be combined with MADM models and optimisation algorithms to serve as the system reasoning engine. The authors’ research team has developed a knowledge base for implementing the interface compatibility rules based on Knowledgeware of Dassault Systèmes to aid designers in achieving automated tests of compatibility among different components [62]. However, considerable effort is still required for the development of an expert system that can realise the automated conceptual design process for mechatronic systems and more complex product-service systems. The main challenge in implementing the proposed approach in an expert system is that it is difficult to transform the heterogeneous design knowledge derived from previous design cases or rules of different disciplines into a common and logical form on the semantic level [63]. Ontology is considered as a potential solution for processing the heterogeneous information on the semantic level [64]. The authors’ research team intends to use an ontology-based approach to solve the aforementioned semantic problem for the design of mechatronic systems [65]; however, numerous further studies need to be carried out in the future. Another main barrier is the manner in which to use mathematical models/expressions to represent diverse quantitative and non-quantitative system requirements, design constraints, manufacturing constraints, and supply chain/network capabilities, among others, so as to facilitate the development of general computational decision making support tools, such as the compatibility checking computational tool in this paper, for complex system design. In the future, the authors will focus on how to combine traditional rule-based or case-based methods with computational models to solve complex interdisciplinary system design problems, as well as more complex product-service systems in an automated manner, with a life cycle view.

6. Conclusion

The paper has proposed a requirement-driven architecture definition approach. To define the architecture of a mechatronic system, the research issues relating to system decomposition and component selection should be paid special attention. The proposed approach addresses the two issues by formalising the conceptual design process, from the specification of design requirements to the final architecture definition. The main contributions of the work lie in the following three levels. Firstly, the authors provide designers with a formulated specification of design requirements, which classifies design requirements into functional and non-functional requirements. Secondly, the decomposition method of the proposed approach allows designers to realise system decomposition based on functional requirements. Thirdly, the component selection method of the proposed approach can aid designers in selecting the most suitable components among various alternatives. The effectiveness and applicability of the proposed approach are demonstrated by two highly different case studies from the academic and industrial areas. Compared to the RobAFIS robot competitions of the past three years, the proposed approach is proven to be more efficient, as the development leading time in RobAFIS 2016 was significantly reduced.

Footnotes

http://www.omgsysml.org/.

http://www.3ds.com/about-3ds/3dexperience-platform/.

Acknowledgments

This project is supported by National Natural Science Foundation of China (grant no. 51805437).

References

Schweiger

Levichev

Schon

Meerkamm

. Digital mock-up in the early stages of mechatronic product design. Journal of Engineering Design. 1999; 10(3): 235-246.

Kleiner

Anderl

Gräb

. A collaborative design system for product data integration. Journal of Engineering Design. 2003; 14(4): 421-8.

Zheng

Bricogne

Le Duigou

Eynard

. Survey on mechatronic engineering: a focus on design methods and product models. Advanced Engineering Informatics. 2014; 28(3): 241-257.

Zhang

Han

. Quantitative optimization of interoperability during feature-based data exchange. Integrated Computer-Aided Engineering. 2016; 23(1): 31-50.

Joly

Verstraete

Paniagua

. Integrated multifidelity, multidisciplinary evolutionary design optimization of counterrotating compressors. Integrated Computer-Aided Engineering. 2014; 21(3): 249-261.

Kapurch

. NASA Systems engineering handbook. Darby (PA): DIANE Publishing; 2010.

ISO/IEC/IEEE 15288. Systems and software engineering – system life cycle processes. 2015.

Medland

Mullineux

. A decomposition strategy for conceptual design. Journal of Engineering Design. 2000; 11(1): 3-16.

Kociecki

Adeli

. Two-phase genetic algorithm for topology optimization of free-form steel space-frame roof structures with complex curvatures. Engineering Applications of Artificial Intelligence. 2014; 32: 218-227.

10.

Tharumarajah

. Application of holonic part-oriented control architecture to a machining line. Integrated Computer-Aided Engineering. 2002; 9(3): 219-233.

11.

ISO/IEC/IEEE 42010. Systems and software engineering – architecture description. 2011.

12.

Komoto

Tomiyama

. Multi-disciplinary system decomposition of complex mechatronics systems. CIRP Annals – Manufacturing Technology. 2011; 60(1): 191-194.

13.

Tsai

Hsiao

. Evaluation of alternatives for product customization using fuzzy logic. Information Sciences. 2004; 158(1): 233-262.

14.

Drake

. Using the analytic hierarchy process in engineering education. International Journal of Engineering Education. 1998; 14(3): 191-196.

15.

Parunak

HVD

Baker

Clark

. The AARIA agent architecture: From manufacturing requirements to agent-based system design. Integrated Computer-Aided Engineering. 2001; 8(1): 45-58.

16.

Zawadzki

Żywicki

. Smart product design and production control for effective mass customisation in the industry 4.0 concept. Management and Production Engineering Review. 2016; 7(3): 105-112.

17.

Aldanondo

Hadj-Hamou

Moynard

Lamothe

. Mass customization and configuration: requirement analysis and constraint based modeling propositions. Integrated Computer-Aided Engineering. 2003; 10(2): 177-189.

18.

Saaksvuori

Immonen

. Product lifecycle management. London: Springer Science & Business Media; 2008.

19.

Hehenberger

. Advances in model-based mechatronic design. Trauner Verlag, Linz; 2012.

20.

Sommerville

Sawyer

. Requirements engineering: a good practice guide. Chichester: John Wiley & Sons, Inc; 1997.

21.

Darlington

Culley

. Current research in the engineering design requirement. Proceedings of the Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture. 2002; 216(3): 375-388.

22.

Macaulay

. Requirements capture as a cooperative activity. In: Proceedings of IEEE International Symposium on Requirements Engineering. San Diego (CA), USA; 1993.

23.

Loucopoulos

Champion

. Knowledge-based approach to requirements engineering using method and domain knowledge. Knowledge-Based Systems. 1988; 1(3): 179-187.

24.

Besbes

Baazaoui-Zghal

. Personalized and context-aware retrieval based on fuzzy ontology profiling. Integrated Computer-Aided Engineering. 2017; 24(1): 87-103.

25.

Bahill

Madni

. Discovering system requirements. In: Tradeoff Decisions in System Design. Cham: Springer International Publishing; 2016. pp. 373-457.

26.

Carroll

. Scenario-based design. In: Handbook of human-computer interaction. Amsterdam: Elsevier; 1997.

27.

Seyff

Maiden

Karlsen

Lockerbie

Grünbacher

Graf

, et al. Exploring how to use scenarios to discover requirements. Requirements Engineering. 2009; 14(2): 91-111.

28.

Freeman

. Software perspectives: the system is the message. Chicago (IL): Addison-Wesley Longman Publishing Co., Inc.; 1987.

29.

Chen

Zeng

. Classification of product requirements based on product environment. Concurrent Engineering: Research and Applications. 2006; 14(3): 219-230.

30.

Hehenberger

. Perspectives on hierarchical modeling in mechatronic design. Advanced Engineering Informatics. 2014 Aug; 28(3): 188-197.

31.

Roman

. A taxonomy of current issues in requirements engineering. Computer. 1985; 18(4): 14-23.

32.

Thayer

Dorfman

. Software requirements engineering. Washington, D.C.: IEEE Computer Society Press; 1990.

33.

ISO/IEC. Systems and software engineering-Vocabulary. International standard ISO/IEC/IEEE 24765. 2010.

34.

Chung

Nixon

Mylopoulos

. Non-functional requirements in software engineering. London: Springer Science & Business Media; 2000.

35.

Mylopoulos

Chung

Nixon

. Representing and using nonfunctional requirements: a process-oriented approach. IEEE Transactions on Software Engineering. 1992; 18(6): 483-497.

36.

Mairiza

Zowghi

Nurmuliani

. An investigation into the notion of non-functional requirements. In: Proceedings of the 2010 ACM Symposium on Applied Computing. New York (NY), USA; 2010.

37.

Zhu

Luo

Chen

. A non-functional requirements tradeoff model in Trustworthy Software. Information Sciences. 2012; 191(9): 61-75.

38.

Letier

Van Lamsweerde

. Reasoning about partial goal satisfaction for requirements and design engineering. ACM SIGSOFT Software Engineering Notes. 2004; 29(6): 53-62.

39.

Chung

do Prado Leite

JCS

. On non-functional requirements in software engineering. In: Conceptual Modeling: Foundations and Applications. Springer Berlin Heidelberg; 2009. pp. 363-379.

40.

Zheng

Hehenberger

Le Duigou

Bricogne

Eynard

. Multidisciplinary design methodology for mechatronic systems based on interface model. Research in Engineering Design. 2017; 28(3): 333-356.

41.

Zheng

Le Duigou

Bricogne

Dupont

Eynard

. Interface model enabling decomposition method for architecture definition of mechatronic systems. Mechatronics. 2016; 40: 194-207.

42.

Vareilles

Coudert

Aldanondo

Geneste

Abeille

. System design and project planning: model and rules to manage their interactions. Integrated Computer-Aided Engineering. 2015; 22(4): 327-342.

43.

Ziv

Alspaugh

Richardson

. An architectural pattern for non functional dependability requirements. Journal of Systems & Software. 2006; 79(10): 1370-1378.

44.

Ameller

Ayala

Cabot

Franch

. Non-functional requirements in architectural decision making. IEEE Software. 2012; 30(2): 61-67.

45.

Zheng

Le Duigou

Bricogne

Eynard

. Multidisciplinary interface model for design of mechatronic systems. Computers in Industry. 2016; 76(2): 24-37.

46.

Zhang

Wang

Bernard

. Embedding multi-attribute decision making into evolutionary optimization to solve the many-objective combinatorial optimization problems. Journal of Grey System. 2016; 28(3): 124-143.

47.

Jia

Wang

Fan

. Multiobjective bilevel optimization for production-distribution planning problems using hybrid genetic algorithm. Integrated Computer-Aided Engineering. 2014; 21(1): 77-90.

48.

Abdi

Labib

. A design strategy for reconfigurable manufacturing systems (RMSs) using analytical hierarchical process (AHP): A case study. International Journal of Production Research. 2003; 41(10): 2273-2299.

49.

Deciu

Ostrosi

Ferney

Gheorghe

. Configurable product design using multiple fuzzy models. Journal of Engineering Design. 2005; 16(2): 209-233.

50.

Rostami

Neri

Epitropakis

. Progressive preference articulation for decision making in multi-objective optimisation problems. Integrated Computer-Aided Engineering. 2017; 24(4): 315-335.

51.

Yang

Emmerich

Baeck

Kok

. Multiobjective inventory routing with uncertain demand using population-based metaheuristics. Integrated Computer-Aided Engineering. 2016; 23(3): 205-220.

52.

Zhang

Bernard

. An integrated decision-making model for multi-attributes decision-making (MADM) problems in additive manufacturing process planning. Rapid Prototyping Journal. 2014; 20(5): 377-389.

53.

Liu

Lin

. Grey systems: theory and applications. New York: Springer; 2010.

54.

Pan

Tian

Zhang

. Region division based diversity maintaining approach for many-objective optimization. Integrated Computer-Aided Engineering. 2017; 24(3): 279-296.

55.

Kyriklidis

Dounias

. Evolutionary computation for resource leveling optimization in project management. Integrated Computer-Aided Engineering. 2016; 23(2): 173-184.

56.

Mencıa

Sierra

Mencıa

Varela

. Genetic algorithms for the scheduling problem with arbitrary precedence relations and skilled operators. Integrated Computer-Aided Engineering. 2016; 23(3): 269-285.

57.

Wang

Szeto

. Multiobjective environmentally sustainable road network design using pareto optimization. Computer-Aided Civil and Infrastructure Engineering. 2016; 32(11): 964-987.

58.

Distefano

Puliafito

. Information dependability in distributed systems: the dependable distributed storage system. Integrated Computer-Aided Engineering. 2104; 21(1): 3-18.

59.

Adeli

Balasubramanyam

. A novel approach to expert systems for design of large structures. AI Magazine. 1988; 9(4): 54-63.

60.

Adeli

Sun

Han

. Hybridizing principles of TOPSIS with case-based reasoning for business failure prediction. Computers & Operations Research. 2011; 38(2): 409-419.

61.

Waheed

Adeli

. A knowledge-based system for evaluation of superload permit applications. Expert Systems with Applications. 2000; 18(1): 51-58.

62.

Zheng

Bricogne

Duigou

Hehenberger

Eynard

. Knowledge-based engineering for multidisciplinary systems: Integrated design based on interface model. Concurrent Engineering. 2018; 26(2): 157-170.

63.

Caíno-Lores

García

García-Carballeira

Carretero

. Efficient design assessment in the railway electric infrastructure domain using cloud computing. Integrated Computer-Aided Engineering. 2017; 24(1): 57-72.

64.

Ramos

Vázquez

Fernández

Olivares-Alarcos

. Ontology based design, control and programming of modular robots. Integrated Computer-Aided Engineering. 2018; 25(2): 173-92.

65.

Guerineau

Zheng

Bricogne

Durupt

Rivest

Rowson

Eynard

. Management of heterogeneous information for integrated design of multidisciplinary systems. In: CIRP Design. Cranfield, UK; 2017.

A requirement-driven architecture definition approach for conceptual design of mechatronic systems

Abstract

Keywords

1. Introduction

2. Literature review

2.1 Capturing of informal requirements

2.2 Requirement specifications

3. Requirement-driven architecture definition approach

3.1 System decomposition

3.1.1 Specification of functional requirements

3.2 Component selection

3.2.1 Specification of non-functional requirements

Table 1 Functional requirements for lunar roving vehicle

4.1.1 Presentation of requirements for lunar roving vehicle

Table 2 Non-functional requirements for lunar roving vehicle

Table 3 Components and their alternatives

4.2.1 Specification of functional and non-functional requirements

Table 9 Non-functional requirements for automated CMC materials cutting system

Table 10 Components and their alternatives

Footnotes

Acknowledgments

References

Table 1
Functional requirements for lunar roving vehicle

Table 2
Non-functional requirements for lunar roving vehicle

Table 3
Components and their alternatives

Table 9
Non-functional requirements for automated CMC materials cutting system

Table 10
Components and their alternatives