Modular Safety Argument Structures

The traditional approach to producing a safety argument for a system is to produce a monolithic safety argument for the entire system under consideration. This means that the entire system is considered as one entity. There is nothing inherently wrong about this approach, and acceptable monolithic safety arguments have been produced for many complex systems. Indeed it would be possible in principle to produce a monolithic argument for an OO system, which successfully made an argument that the system was safe to operate. In this section, however, it will be shown that using a monolithic structure for the safety argument has certain drawbacks and, instead, an alternative modular approach is more appropriate for OO systems.

In chapter 2 GSN was introduced as an effective notation for representing safety case arguments.

In this chapter GSN shall be used to represent the safety argument structures. Initially different modular argument structures will be considered. These can be represented using the module and away goal extensions to GSN [30]. A module is a self-contained component of the argument and supporting evidence relating to a particular aspect of the safety case for the system. Figure 5.1 shows a modular representation of the monolithic safety argument. As such only one argument module is required. This module contains the safety argument and evidence relating to all of the classes in the whole of the system under consideration.

OOSystemArg

Argument concerning the whole OO System

Figure 5.1: Monolithic safety argument structure

In assessing whether a particular argument structure is good for an OO system, the criteria that shall be used are the same as have been considered throughout this thesis. That is that the argument structure is robust in the face of changes to the system design, and that the structure supports the reuse of design elements. Therefore, the amount of the argument that is affected by a change to a system design should be as small as possible. A change to a design will effect a module if the argument within that module relates to the changed part of the design in some way. It should also be possible to identify and isolate modules of the argument relating to specific parts of the system design, such that if that part of the system were reused in another system design, the corresponding module may also be reused as part of the safety argument for the new system. This will reduce the effort required, compared with developing the relevant

argument module from scratch.

When considering the monolithic safety argument structure, there is found to be very poor support for change. Since there is just one argument for the whole system, the argument contained within the module will commonly (and almost inevitably) contain a large web of argument dependencies between different elements of the argument. Although the argument produced could be valid, any change to the design of the system would affect large parts of the argument. This would mean that in order to remain valid for the changed design, the whole argument would, in effect, need to be revisited. Since the arguments produced can be extremely large, this could represent a huge effort. In addition, it could be potentially very difficult to identify the parts of the argument that have been affected by the change. Due to the monolithic structure, the effects of the change could be spread throughout the argument, making it difficult to identify the affected parts.

If part of the design were reused in another system then it would be extremely difficult, with this argument structure, to reuse the corresponding part of the safety argument in the argument for the new system. The argument is very highly coupled, and therefore separating out the argument relating to the particular element of the system being reused, without losing important elements of that argument, would be very difficult. It is for these reasons that it is felt that this traditional approach to constructing a safety argument is insufficient to retain the desirable features of OO designs. An alternative argument structure is therefore required.

Figure 5.2 shows another possible argument structure that might be used. In this structure, the top-level argument module provides the scope of the overall system argument, and the child modules present independent safety arguments about the classes in the system design.

The links between the modules indicate that a claim in one module is solved by the argument contained in another module. These links are made using away goals as illustrated in section 5.3. Evaluating this argument structure in a similar manner to the monolithic structure reveals some interesting observations. It can be seen that this structure has better support for change than the monolithic structure. Because there is a separate module containing the argument relating to the safety of each class, it is easier to identify the impact of design change on the argument structure. For those classes which have been changed in the design, the relevant class argument module will also have been affected, and must be updated to reflect the change. For those classes that have not been changed, the corresponding module will remain unaffected.

Due to the separation in the argument there are no knock-on effects throughout the argument structure.

Class Z Arg Class Y Arg

Class X Arg

Software System Arg

Figure 5.2: Modular argument structure including class modules

Another type of change that would commonly be encountered is to introduce a new class into a system design. At first it would seem that the argument structure in figure 5.2 supports this type of change, as a new argument module relating to that new class could be added to the structure. In fact, things are more complicated than that, and this structure is far from ideal.

It has been seen throughout this thesis how the interactions between class objects in the system are crucial to the behaviour, and hence the safety of the system. In the structure in figure 5.2, the argument about the safety of the interaction between the classes is contained within the class argument modules themselves. When a new class is added, it may interact with a large number of the other classes in the system. Therefore the addition of a new class will also affect the argument modules of all the other classes with which that class interacts.

It would similarly appear that there is a greater reuse potential with this argument structure.

It is now easier than in the monolithic case to identify the relevant part of the argument to be reused. However, due to the dependencies that exist between modules, resulting from the interactions, the reuse potential of the argument modules is also limited. When an argument module is reused the interactions will change from those with other classes in the old system to those in the new. This may require a great deal of reworking of the argument module for it to be valid in the new system. This could negate the advantage gained from reusing the argument module.

The problems associated with the previous argument structure can be dealt with by introducing a module which deals explicitly with the safety argument about the interactions between classes.

This argument structure can be seen in figure 5.3. In this structure, an argument about all the interactions is made in a separate module. There are no longer any links between the class argument modules as the class arguments no longer have responsibility to reason about their effect on other classes. The individual class argument modules now just make an argument

that they will meet any constraints arising on them from these interactions. As a result of this, handling changes to the system design is now much easier. For example, introducing a new class to the system design, in addition to a new argument module for the new class will primarily impact just the interactions module. This will be changed to handle the new interactions introduced. There is no longer a knock-on effect on the rest of the argument, as there was with the other argument structures.

Software System Arg

Class X Arg Class Y Arg Class Z Arg

Interactions Arg

Figure 5.3: Modular argument structure with separate interactions argument

The structure also provides better potential for reusing parts of the argument. As stated earlier, because of the interactions module, the class modules no longer need to reason about other classes in the system as part of their argument. This means that any of the class argument modules could be used as part of the argument for a different system with minimal rework required. It is for these reasons that the argument structure in figure 5.3 is proposed as the most desirable for presenting a safety argument for an OO system. Later in this chapter, the effects of change and reuse on the safety argument itself will be considered in more detail. Firstly it is necessary to develop those arguments, which are contained within each of the argument modules. In the next section patterns for the arguments are presented in GSN. These patterns can be instantiated for the OO system to which they are applied.