Tải bản đầy đủ - 0 (trang)
4 Use Case 1: Stepwise Refinement of Design Requirements

4 Use Case 1: Stepwise Refinement of Design Requirements

Tải bản đầy đủ - 0trang

12 Semantic Web Solutions in the Automotive Industry


Fig. 12.5 The architecture of the requirement management system

The scenario that we will use to explain the application that we built is in the

context of the layout phase in the development of an engine. In the layout phase, the

structure of the engine is already known, but optimizations of the parameters of the

components are still performed. The goal is to obtain a design that is optimal with

respect to some cost function and that does not violate any constraints.

In the layout scenario, the geometry of the motor has to be improved such that the

compression ratio6 of the engine will be increased. The compression ratio depends

on a multitude of geometrical parameters of the engine.

Our task was to develop a requirement management system that will support:

∙ The stepwise refinement of the design parameters,

∙ The consistency checking of the design based on the defined constraints,

∙ In case that the design is inconsistent, meaning that at least two constraints are in

conflict, the application should support the automatic solving of the conflict based

on some cost function of the constraints,

∙ Support the allocation of requirements to parts and the tracking the requirements’

history, and,

∙ Support for reuse of parts and requirements based on libraries.

12.4.1 The Requirements Management System

The main components of the Requirement Management System and their interdependencies are shown in Fig. 12.5.


The compression ratio is a very important parameter of the engine that describes the efficiency of

the engine. The greater the value, the better the engine.


T. Tudorache and L. Alani

The Requirements ontology7 provides the framework for modeling of requirements, for their allocation to parts of the systems, for attaching constraints to requirements and parts of the system and also keeping track of different versions of requirements. Systems and their components are represented as classes in the ontology.

Classes have different attributes, which are modeled as slots. In order to handle the

stepwise refinement of the attributes values, a new attribute type was developed. This

attribute type (modeled as a meta-slot in Protégé) has representations for the values

corresponding to each processing step.

We used a constraint engine to solve the constraint system resulting from the

design requirements. The constraint engine we used in the architecture is the Relational Constraint Solver (RCS) (Mauss et al. 2002), that supports different types of


∙ linear equations and inequations, such as 2x + 3y < 0. The coefficients may also

be intervals with open or closed boundaries, e.g., [2.8, 3.2).

∙ multivariate polynomial, trigonometric, and other non–linear interval equations,

such as x = sin(y), x = sqrt(y).

∙ assignments of symbols to variables, such as x = blue

∙ disjunctions (or) and conjunctions (and) of the above relations, such as x = red ∨

x = blue

The Constraint Processing Logic is responsible for the stepwise refinement of

the design parameters. The Automatic Conflict Solver takes a conflict between two

or more constraints as an input and generates a list of possible solution ordered by a

cost function.

12.4.2 The User Interface

The graphical interface of the requirement management system (Fig. 12.6) has been

implemented as a plug-in for Protégé8 and provides support for:

Viewing the attributes that are involved in a constraint system,

Viewing the constraint system,

Viewing the conflicting constraints,

Editing the input values for any processing step and attribute, and,

Inconsistency detection and conflict solving.

7 The Requirements ontology presented in Sect. 12.3.6 has been developed based on the experiences

gained from this project. The ontology used here contains also the definitions of components and




12 Semantic Web Solutions in the Automotive Industry


Fig. 12.6 The GUI of the requirement management system. The left part of the display shows the

Requirements class hierarchy. The upper part shows a list of all variables involved in the constraint

system. Each variable is associated to an attribute of a class. The bottom–left window shows a list

of the constraints in the constraint system. The bottom–right panel shows a list of the constraints

which are in conflict after executing the consistency checking

12.4.3 The Requirements Ontology in SDD

The Requirements ontology is used to model the requirements and their interrelationships, such as hasPart—for the representation of the requirements decomposition—

or is_derived_into—to represent the evolution of requirements. An excerpt from the

Requirements ontology is shown in Fig. 12.7. Constraints may be attached to requirements or to specific parts of a system, modeled as Components.

The ontology supports the modeling of requirements and component templates by

representing them as classes. A specific requirement can be modeled as an instance

of a requirement class or as a subclass. The stepValue attribute attached to the Component class is a complex attribute that stores the values of a simple attribute in different processing steps. In this project, each attribute (represented as stepValue) was

described by three values: BereichMinMax—the minimum and maximum values for

this attribute, BereichOpt—the optimal interval of this attribute, and CatiaInput—

the actual value (not interval) that goes into the CAD system (in this case, Catia

was used). The constraint system would first try to solve the system using the more

generic values and would refine the values in consequent refinement steps.

By modeling requirements, components, constraints and their relationships explicitly, the ontology improved substantially the correctness of models. The engineers

were not allowed to enter incorrect information, because the knowledge acquisition


T. Tudorache and L. Alani

cd: Requirements

+ hasPart *



+ fulfilled_by



+ fulfills

+ isPartOf

+ verifies

+ usedIn

+ usedIn

+ hasConstraint

+ verified_by


+ hasConstraint


Fig. 12.7 An excerpt from the Requirements ontology

process was constrained and guided by the ontology. For example, an attribute of a

requirement is the status describing the fulfillment of the requirement in the model,

which can take only three predefined values (passed, failed, not verified) and which

must have a value. When editing the requirements of a component, the engineer had

to enter one of the allowed values for the status attribute. He was prevented from

entering an invalid value for that attribute.

Managing the complex network of requirements and model parameters using this

approach has proved to be much easier than it was with the existing approaches.

Once the constraints were represented explicitly, the consistency of the model could

be checked in an automated way by the constraint engine.

12.4.4 The Constraint Processing Logic

The constraint processing logic defines the flow of operations and data and describes

how the information in one processing step affects the information in the next

processing step. A rule is that each processing step is more restrictive than its predecessor. Even more, the actual input value of a step is the intersection of the user

input value for that step and the output value of the predecessor step.

This can be formally described by:

constrInputValuei = constrOutputValuei-1 ∩ userInputValuei

In this way, it is ensured that a processing step is more restrictive than its predecessor.

Each constraint attribute has a state that depends on which processing step is

processed at a certain time. This is implemented by a counter that shows what

processing step is currently active. For example, if the user is working in the processing step BereichOpt, then the current counter is 2, because BereichOpt is the second

12 Semantic Web Solutions in the Automotive Industry


step of processing. After completing step two, the processing logic activates the next

processing step (the one with orderNr = 3).

The representation of the constraint attribute type is very flexible, so that it is

straightforward to add a new processing step, a processing step property, or to change

the name of a processing step.

12.4.5 The Automatic Conflict Solving

If the constraint system defined in the ontology is consistent, then a design solution

for a particular processing step is obtained. However, if the resulting system of equations is inconsistent, then we have to relax (i.e., remove) some constraints in order

to obtain a consistent state of the system.

The process of choosing what constraint to relax can be done manually by trying

different alternatives until a solution is found. However, this process is very tiring and

complex. Even if a constraint is relaxed, it is not guaranteed that the new constraint

system is consistent.

In order to solve this problem, we developed an algorithm for the automatic conflict solving. This algorithm provides the user with several conflict solving alternatives. It returns a list of constraints that can be relaxed in order to obtain a consistent

system, sorted by the values of a cost function. The algorithm may also be optimized by different factors. The full algorithm is presented the appendix of (Tudorache 2006b).

12.4.6 The SDD Application at Runtime

We developed an ontology with the structural representation of an engine, which also

contained all the qualitative requirements represented as mathematical constraints

(see Sect. 12.4.1). The engine was composed of 137 parts, which were constrained

by 71 constraints containing 279 variables. The variables were linked to specific

parts using the path representation mechanism described in Sect. 12.3.7. These constraints varied from linear equations and inequations to multivariate polynomial,

trigonometric, and other non–linear interval equations, as well as custom functions

to read-in values from Excel spreadsheets. We used three steps for the iterative constraint processing: we started with interval values for most variables, which were

then iteratively optimized, and in the thrid step the optimal concrete value was chosen. The constraint solver (RCS) was efficient and solved the constraint system for

one processing step in 2–3 s.


T. Tudorache and L. Alani

12.4.7 Benefits of an Ontology–Based Approach

We applied the ontology–based Requirements Management System in different scenarios, and we were able to successfully find optimal design solutions in each of

them. One of the advantages of using an ontology–based approach is that it enabled

reusing previous knowledge. We defined a library of components and requirement

templates that we were able to instantiate in different design problems.

We saw another benefit coming from the structured information acquisition that

prevented the engineer from entering incorrect information in a design model.

The definitions of component templates are represented as a classes in the ontology.

The classes serve as templates for building instances that represent a concrete design

model. Therefore, all constraints defined in a template component (at class level) are

checked for a concrete design model (at instance level). An intelligent model editing

environment can interpret the constraints defined for the template components and

prevent invalid input in a concrete design model.

Enabling consistency checking in iterative steps and documenting the history of

parameter values was a huge improvement over the existing Excel–based solutions.

The constraint system contained several complex constraints involving the parameters of the design model, which were impossible to manage in Excel. By using the

ontology–based approach, we were able to reduce the complexity of the product,

and to make it more manageable.

12.5 Use Case 2: Mapping and Change Propagation

between Engineering Models

The second use case comes from a research project at an automotive company

related to the development of an automatic transmission gearbox of a car. The automatic transmission is a complex mechatronic component that contains mechanical,

hydraulic, electrical and software parts, that need to interoperate in order to achieve

the overall functionality of the product.

The development of the automatic transmission is made in a parallel fashion by

different engineering teams. One team of engineers develops the geometrical model

of the gearbox and another team develops the functional model of the same gearbox.

The developed models are different in several ways. First, they are represented in

different modeling languages. Second, they have different conceptualizations of the

gearbox: One models the geometrical characteristics of the product, while the other

represents the gearbox as a composition of functional blocks coupled together. However, there are certain correspondences that interrelate the two design models. For

instance, a parameter from the functional model, ratio of the gearbox is computed as

a function of two parameters in the geometrical model. In the following, we will use

the keyword viewpoint to refer to the geometrical or functional development branch.

12 Semantic Web Solutions in the Automotive Industry


The project required that a framework should be implemented that will support

the consistency checking between the two design models, as well as, the change

propagation from one model to another.

The full details about the implementation of this project can be found in Chaps. 5

and 6 of (Tudorache 2006b).

12.5.1 Mapping Between Libraries of Components

The engineers build the functional and geometrical models using model libraries

from their respective tools. Therefore, a model is composed by instantiating template

components from the model libraries and by interrelating them. Figure 12.8 shows

this situation.

The libraries and the design models are represented in different modeling languages. The names used for corresponding components in the two model libraries

are different. The CAD library uses German names, whereas the functional library

uses English names for the components.

However, the design models built from these component libraries still have one

thing in common: They represent the same product from different perspectives. As a

consequence, there will be correspondences between the structures and parameters

of the models in the two libraries, shown in Fig. 12.8. We defined the correspondences, also known as, mappings, between components of the library. In this way it

is possible to reuse them between all instances of corresponding templates. To map

an entire system, we need to be able to compose the mappings between components.

Fig. 12.8 Mappings between component libraries in two viewpoints

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

4 Use Case 1: Stepwise Refinement of Design Requirements

Tải bản đầy đủ ngay(0 tr)