31.01.2014 Views

Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 5. Verification and Validation<br />

Development of<br />

train control meta model<br />

Development of<br />

model constraints<br />

D<strong>es</strong>ign and implementation of<br />

code generators<br />

for the meta model<br />

D<strong>es</strong>ign of domain framework<br />

Definition of<br />

model constraints<br />

Dynamic T<strong>es</strong>ting<br />

(of gen. code)<br />

Development of<br />

model of<br />

train control standard<br />

Implementation of<br />

domain framework<br />

Model Constraint<br />

Checking<br />

Dynamic T<strong>es</strong>ting<br />

D<strong>es</strong>ign and Implementation of<br />

Verification & Validation Suite<br />

Verification<br />

Validation<br />

time<br />

Figure 5.2.: Software development life cycle for DSM in the railway domain<br />

Requirements Specifications [11].<br />

To directly integrate verification and validation in the development proc<strong>es</strong>s, the original tool<br />

chain for the GOPPRR meta meta model extension (see Section 4.6) has to be extended, which<br />

is shown in Figure 5.3. The generator for functional t<strong>es</strong>ting [78, p. 316] refers to a concrete<br />

dynamic t<strong>es</strong>ting category that should be applied.<br />

It must be emphasised that this extended tool chain still is very general since it do<strong>es</strong> not yet<br />

take the domain framework into account, which always heavily depends on the concrete meta<br />

model. Furthermore, the code generation also depends on the domain framework because it<br />

builds the link between models and the framework. Thus, a complete or rather more concrete<br />

tool chain is given in Part III for a certain example in form of a case study.<br />

5.4. Conclusion<br />

This chapter introduced standards for safety-critical systems and discussed the issu<strong>es</strong> for<br />

software development of such systems. B<strong>es</strong>id<strong>es</strong> standards directly related to the domain of<br />

train control systems, also a general standard in form of the DIN EN 61508 was exemplary<br />

introduced. The DO-178B for airborne systems was used to additionally introduce principl<strong>es</strong><br />

and techniqu<strong>es</strong> for a complete different problem domain.<br />

Since all standards are life cycle oriented, a specialised software life cycle was developed,<br />

which directly integrat<strong>es</strong> the development of a DSL for a certain train control standards in<br />

general. Also, consi<strong>der</strong>ations for the development as FLOSS were taken into account.<br />

The general tool chain for the GOPPRR meta model was extended about the integration of<br />

verification and validation according to the consi<strong>der</strong>ations related to the standards. Neverthel<strong>es</strong>s,<br />

the integration of the software life cycle for DSM into the life cycle of the EN 50128 cannot be<br />

realised in the case study because it would exceed the limits of a dissertation.<br />

62

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

Saved successfully!

Ooh no, something went wrong!