Information Technology Reference
In-Depth Information
AF has been added two new ports. Similar ports were added also to the controller block
(see figure 7) and its equations.
The simulation result related to the second, improved interlocking AF is presented
in figure 10b. The speed request obtained from the operator is similar to that of the first
simulation. In this case, the cart is smoothly decelerated already before reaching the
limit and the overshoot is much smaller than that in the first simulation. Clearly, this
alternative provides a better control performance as even in case of strict safety limits,
the cart would not need to be stopped with the brake before the actual limit.
6
Towards Development of Certifiable Safety Functions
The use of model-based techniques in development of safety-critical applications has
not been recommended by safety standards, such as IEC 61508, until recently. How-
ever, due to the new version of the standard, they could be used, for example, during
architecture design to aid the completeness and correctness of design as well as freedom
from intrinsic design faults.
Perhaps the most essential difference between the development of safety systems and
basic control systems is that safety systems require extensive documentation about all
the development activities and their results for verification, validation and certification
purposes. The development of safety systems should also be risk-driven so that the
requirements and design artefacts could be always traced to the perceived safety needs
which originate from risk and hazard analysis. When assessing the quality of design,
design artefacts could be compared to the original safety needs and when in doubt,
developers could always refer to the risks and hazards.
We are currently striving to extend the scope of UML AP to cover also the develop-
ment and design of safety systems. The work is targeted to the requirement concepts
of the profile (see [6]) but also to documenting the results of risk and hazard analysis.
Including the risk and hazard information in a compact form in the same models with
the design would not only enable the use of explicit traces between them but also aid
the discovery of the information when the developers need it. Moreover, compared to
use of separate documents, a unified (one) model could be easier to maintain and keep
up-to-date if and when something needs to be changed in design.
An admitted difficulty in development of both safety critical and basic control sys-
tems is related to the specification of requirements. In development of safety-critical ap-
plications, the functional requirements (what the system must do) originate from hazard
analysis and the non-functional requirements (how well it must be done) from risk anal-
ysis. However, unambiguous and complete specification of the functional requirements
is still difficult. Perhaps this task could be facilitated with a semi-formal, domain spe-
cific modelling approach. Another working direction is the ability to simulate designs
and specifications.
In [8] the author has analysed the quality of produced software in about 12500
projects from year 1984 to 2008 and the defects delivered (and removed) during the
projects. The results may not be directly generalizable to safety-critical applications as
such. However, according to the survey, also in the best-in-class-quality, a significant
portion of defects delivered were related to defects in requirements specifications, partly
because defects in requirements are difficult to discover.
Search WWH ::
Custom Search