Assurance case modules can be connected through three types of interfaces as they are defined in GSN Community Standard version 3:
- Away elements (citation)
- Support by module
- Support by contract
In our post in May we presented a diagram comparing the types of interfaces but the presented diagram was a bit too simplified. An important feature of argument contracts was missing. To correct this we have updated the diagram and we present it below. We have added the contract symbol between the modules and additionally the assessment icons.
Graphical argument representation in NOR-STA is only available for GSN argument notation. An example of a GSN diagram containing the base types of elements is shown below.
An assurance case contract is valid when the claim published in one module supports the claim in another module in its full context. When this condition is not satisfied then the contract is not binding. The status of the contract is presented in NOR-STA with the use of the assessment
- The contract which is not verified yet has ‘unknown’ status and yellow assessment icon.
- When the contract is verified and accepted then the assessment icon is green. This means that the contract is valid and the modules are effectively bound.
- Failure of the contract verification causes its rejection. The icon becomes red and the contract is not valid.
The modules are considered to be connected only when the contract had been verified and it had been confirmed it is valid.
Contracts are the tool to control module bindings. First of all, linking modules is not automatic and requires contract verification. You have to check if you connect the right claims in the right context. Additionally, when any of the bound claims are modified, then the contract automatically becomes outdated and it requires re-verification.
Contract verification is based on a simple pattern with two claims connected with a strategy. Both claims are accompanied with the related context elements and assumptions.
This pattern looks simple however the verification of the context may be tricky in some cases. It can be partially automated by listing inherited context elements when they are specified for higher-level claims. This can reduce the work of manually checking the inherited context. Problems arise when the context is specified in the description of claims, and not as a separate context element. Contextual information may then be easily omitted during the contract verification. The recommended practice is to specify full context of the claims in the argument when you plan to use contracts in the interfaces.
A separate topic is the comparison of the scope of the context of both bound claims. This is usually easy when you develop yourself both modules and refer to the same context terms and documentation. However when the modules are developed independently by different teams, the verification of the context consistency may become difficult. To avoid or to make the problem less severe the involved parties can agree on the context for each assurance case module before starting its development.
A solution for the described problem is the use of shared context model which defines terms used in all connected assurance case modules. An example of such model can be ODD (Operational design domain) which is used in automotive industry. Context modeling is an interesting topic and we will write about in one of our next posts.