25.07.2014 Views

pdf download - Software and Computer Technology - TU Delft

pdf download - Software and Computer Technology - TU Delft

pdf download - Software and Computer Technology - TU Delft

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Diagnosing the Beam Propeller Movement<br />

of the Frontal St<strong>and</strong> 5.4 MBD Implementation 1<br />

5.4.2 The Modeled Structure<br />

The structure of the model is shown in Figure 5.3. In short, this block diagram describes the following.<br />

The input of the target system is the speed the user requests (V_user). The controller of<br />

the movement controls the the output of the target system: the angular speed of the frontal st<strong>and</strong><br />

(speed). It does so, by using three control loops. Note that the fault detection mechanism is part<br />

of the architecture. It constitutes of the POSITION_ERROR, SPEED_ERROR, CURRENT_ERROR <strong>and</strong><br />

POSVAL_ERROR signals. These signals are also chosen as being outputs of the system. During nominal<br />

behavior of the system these four error signals are false (Appendix B.3). The LYDIA model that<br />

defines the nominal behavior is listed in Appendix C.3.5.<br />

This model, that is part of the first MBD implementation, specifies the target system with a<br />

certain granularity. The chosen granularity is motivated by the following two considerations:<br />

• the choice of PMS what components can be replaced with new FRUs, <strong>and</strong> which cannot. This<br />

is the reason that the potentiometer <strong>and</strong> encoder are combined to one entity (PEU). The motor<br />

<strong>and</strong> brake are also combined (MBU), because it is impossible to replace one without the other.<br />

• the possibility to use system data to distinguish between faults. For example, a fault of the<br />

St<strong>and</strong> could, on a lower level of abstraction, be caused by numerous anomalities: oil, a<br />

power from the environment, etc. In some cases, these ’lower’ faults can be recovered by the<br />

service engineer, but the system data cannot reveal them. Thus, these low-level faults are not<br />

represented by health variables in the model.<br />

The model listed in C.3.5 is not compositional. Thus, the structure is not explicitly modeled.<br />

This is a practical form of the model during development, but in order to allow long-term maintenance,<br />

a compositional model is much more appropriate. Appendix C.3.2 shows a compositional<br />

version of the model belonging to the MBD-1 implementation. In this model, each health variable<br />

belongs to separate component. Each component is modeled as a separate entity. The structure is<br />

defined by the top level entity of the model; FS_ Beam_ Propeller_ Movement. Each component<br />

defines part of the behavior. The behavior is discussed in the following subsection.<br />

5.4.3 Behavior of the Model<br />

A block diagram as shown in Figure 5.3 only shows structure, <strong>and</strong> only developers of the system<br />

are able to underst<strong>and</strong> how these components emit the intended behavior. The components of the<br />

compositional model LYDIA model do specify how the components implement the beam propeller<br />

movement of the frontal st<strong>and</strong> (see Appendix B.3 for a description of nominal behavior in natural<br />

language). It is a weak fault model. None is said about what happens if, for example, the MBU<br />

malfunctions. To give insight in how the models specifies the nominal behavior of the system, the<br />

writing below describes two important building blocks of the model: a control loop <strong>and</strong> an error<br />

signal.<br />

Modeling a Control Loop<br />

A very interesting issue of the beam propeller movement subsystem is that it consists of control<br />

loops. Because of their recursive nature the model should embed state <strong>and</strong> time. However, these<br />

issues are still topic of ongoing research. Therefore, the text below suggests an abstraction of<br />

a control loop that does not depend on time <strong>and</strong> state. Figure 5.4 shows successively the block<br />

diagram of one, two <strong>and</strong> three control loops.<br />

59

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!