pdf download - Software and Computer Technology - TU Delft
pdf download - Software and Computer Technology - TU Delft
pdf download - Software and Computer Technology - TU Delft
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