2025 - Argevide

Eliminative Argumentation

Andrzej Wardziński — Fri, 05 Dec 2025 16:52:07 +0000

Eliminative argumentation is an alternative approach to building an assurance case. The argument is typically constructed positively and focuses on demonstrating why we believe the goal has been achieved. Eliminative argumentation relies on the constant questioning of “what if?”. The structure of the argument can be quite similar to that of a standard positive argument, but the focus is on identifying weaknesses in the argument that hinder its purpose. This is achieved by explicitly pointing out possible weaknesses as defeaters and then explicitly demonstrating that they are not valid. The strength of this approach lies in the explicit presentation of all known defeaters. This avoids the error of excessive optimism and distorting the facts to suit the intended purpose.

The process of building an eliminative argumentation is also slightly different. For each step of reasoning, starting with the top claim, an analysis is performed to identify all possible reasons why the goal cannot be achieved. Each obstacle is explicitly described in the argument as a defeater. In the next step, for each defeater, an argument must be found, supported by evidence, that a given defeater is ineffective. For this argument, it is also necessary to examine possible further defeaters that could render it ineffective. The work on the argumentation continues until no more defeaters can be identified and all defeaters have been successfully rejected.

We will examine the application of the eliminative argumentation approach using a simple example taken from the first publication on this approach, the 2015 SEI report “Eliminative Argumentation: A Basis for Arguing Confidence in System Properties.” The purpose of the argument is to demonstrate that the light in the room is working.

Now let’s look at this using the eliminative argumentation approach. The main goal will be the same, but we don’t create a positive strategy around it. Instead, we look for conditions that might prevent the bulb from turning on. We add these conditions as “unless…” stipulations. We start by saying that the bulb will turn on unless there’s no power. Next, we can say that the bulb will turn on unless the switch is not connected. Once the list of known problems is exhausted, we can add “unless another, as yet unknown, problem occurs.”

The condition for completing this step of the argumentation development is the lack of knowledge of other possible defeaters. If we learn of any other possible reason that could prevent the proposed postulate from being met, it should be added as another defeater.

For each deeater identified in the argument, you must now provide evidence that the given defeater will not occur in your system. This may be described by one or more claims or a strategy supported by an argument. It is important to present convincing evidence that the defeater doesn’t pose z risks or the risk is sufficiently low. For unknown defeaters, you should demonstrate that you have completed enough identification activities and identified enough of them that continuing will no longer provide any benefit in reducing the risk level.

The resulting argument has a similar structure to the traditional approach, but it explicitly states the defeater challenging the argument goals. In our example, the list of evidence is almost identical. The only difference stems from the fact that justification J1 in the first diagram is not supported by any evidence.

Although it requires more work, eliminative argumentation has the advantage that it explicitly presents defeaters, which facilitates argument verification. This allows for a potentially higher level of argument quality and trustworthiness.

This approach can now be used in PREMIS. The methods of arguments presentation and the assessment functions have been extended to include a new type of argumentation elements, defeaters.

Artykuł Eliminative Argumentation pochodzi z serwisu Argevide.

Managing system limitations in safety assurance cases (SOTIF)

Andrzej Wardziński — Thu, 20 Nov 2025 13:56:01 +0000

Safety cases are usually based on functional safety arguments to demonstrate that failures will not result in hazardous situations. But accidents may have causes related to the system behaviour different than failures. This is where SOTIF comes in. This stands for Safety of the Intended Functionality. What does it mean? It covers mitigation of hazard factors related to unexpected situations or system limitations. One example of an unexpected situation is bright sunlight making it difficult for an autonomous vehicle to identify lanes. Another example is a system misuse, such as a system operator giving commands that is not foreseen for the current operation mode. SOTIF helps us assure safe system behaviour in unexpected situations.

SOTIF extends functional safety

Functional safety focuses on the risk arising from system faults or failures, i.e. hardware or software malfunctions. In the automotive sector, this is described in the ISO 26262 standard. Safety assurance for other causes related to system limitations and unexpected situations are regulated in the SOTIF standard ISO 21448.

The SOTIF safety assurance process involves a few steps:

The boundaries and scope of the intended functionality must be defined within the Operational Design Domain (ODD).
System behaviour is analysed for potential unsafe scenarios.
Mitigation measures are identified, which can be related to functional modifications to achieve SOTIF goals.
The planned mitigation measures are implemented and verified.
Validation is performed under diverse and representative conditions.
Field monitoring for SOTIF evaluation and maintenance is defined for implementation during system operation.

SOTIF arguments

SOTIF implementation needs to be demonstrated in the system safety case. Guidance how to do this and examples of GSN arguments are provided in ISO 21448. A sample top-level argument for the pre-release SOTIF process of safety assurance is presented below. A separate claim is specified for each main phase of the SOTIF process.

This argument should be extended to include a second branch of the argument for the operational phase of the system life cycle. This argument is focuses on demonstrating the capabilities of the SOTIF safety maintenance process, since the argument is to be developed and approved before the system operation starts. During the system operation this can be supplemented with evidence that these actions are actually performed.

As SOTIF extends functional safety, there is a question how these two arguments relate to each other. There are a few common actions or work products shared between functional safety and SOTIF, such as:

identified hazards,
limitations and assumptions of functional safety,
safety goals and safety requirements,
safety requirements verification and validation.

You can develop separate assurance case modules for functional safety and for SOTIF, they can refer to shared artifacts where necessary. Probably, you will need a claim to demonstrate that functional Safety and SOTIF measures are consistent and jointly sufficient to achieve the acceptable system risk level.

You can browse the sample SOTIF assurance case online in PREMIS using this link.

Summarizing, joint SOTIF and functional safety assurance case covers hazards related to both failures and system limitations including unexpected situations. ISO 21448 is dedicated for automotive sector but this approach is also useful in other industries.

Artykuł Managing system limitations in safety assurance cases (SOTIF) pochodzi z serwisu Argevide.

LTAC – Simple text assurance case format

Andrzej Wardziński — Thu, 30 Oct 2025 04:41:04 +0000

When working with assurance case arguments, a simple text argument format can be useful. This should be understandable to humans and usable with AI tools, while also being formally defined so this can be imported into assurance case editors. For this purpose, we are introducing LTAC – Lightweight Text Assurance Case. It’s a simplified text format for presenting assurance case arguments. Let’s look at an example argument. Is it easy to read and understand?

- Claim G1: System is acceptably safe to operate
  - Context C1: System Definition
  - Strategy S1: Argue by mitigating all hazards
    - Claim G2: All  hazards have been identified
      - Evidence E1: Hazard analysis report
    - Claim G3: All identified hazards have been mitigated
      - Strategy S3: Decompose mitigation argument by identified hazards
        - Claim S5: All identified hazards have been accurately assessed
        - Claim S6: Mitigation strategies have been implemented for all hazards
        - Claim S7: The effectiveness of the mitigation measures has been validated
    - Claim S4: Continuous monitoring of risks is in place

The above argument fragment is human-readable, which is crucial. It can easily be reviewed and modified as needed.

When this argument is pasted into PREMIS, we get the GSN diagram as shown below.

LTAC arguments can be created manually, but also using AI tools or scripts. If you want to use an AI tool, first give it an instruction to use LTAC notation according to the LTAC specification. Once the AI tool learns the LTAC notation, it can easily create and analyse arguments in this way.

As the argumentation gets larger, this textual form becomes more difficult for humans to review. However, the argument fragments in LTAC are still easy to use.

There’s another major limitation to LTAC. This text-based argumentation is effective when there are no argument element descriptions or metadata, such as ‘undeveloped’ tags or other similar information. In such cases, more advanced textual notations, including those using YAML, can be used. However, when the data for a single argument element is more complex and not presented in a single line, it becomes more difficult for manual analysis.

LTAC is an effective solution when you use AI tools and want to review the argument before inserting it into the assurance case tool. It works well with PREMIS.

Artykuł LTAC – Simple text assurance case format pochodzi z serwisu Argevide.

Using confidence arguments in assurance cases

Andrzej Wardziński — Tue, 21 Oct 2025 12:06:10 +0000

Confidence arguments help to justify that main arguments in assurance cases are sound and trustworthy. While the main argument directly addresses system safety or security, the purpose of the confidence argument is to answer the question why we should trust that the main argument is right. Some standards and guidelines, and also some certifiers require an explicit demonstration of the confidence argument, that is a consistent and complete justification that the main argument is trustworthy.

The starting point is demonstrating confidence in a single argumentation step. There are a few ways how you may do this. Here, we present the use of Justification type of argument elements. GSN Community Standard version 3 in section 1:2.2.18 says: “A justification can also be connected to a strategy, to provide backing for the argument described by the strategy.” That’s the point. We need explicit backing for the argumentation reasoning step described by a strategy. The backing should say why should trust that the reasoning is sound, it covers the full context of the claim, all required premises are available and all known problems or weaknesses are resolved. To create such backing we have extended the Justification element to allow it to be supported by an argument. We also allow justifications to be linked to confidence claims. This approach allows to keep the main argument and the confidence argument separate.

PREMIS extends the GSN argument structure to allow justifications to be supported by arguments. The diagram below shows on the left a simple safety argument with justification J1 that is a link (a citation) of a confidence claim CC1. Its argument structure is presented on the right. This example illustrates how the confidence argument can be implemented and how it is related to the main safety argument.

This approach can be used for individual argumentation steps and for complete assurance cases.

The main argument asserts that an acceptable level of system safety has been achieved. Each claim in this argument contributes to achievement of the system safety.
The confidence argument should justify that each argumentation step of the main argument is valid. This does not contribute directly to the system safety, but it is required to trust in the main safety argument. If we cannot provide a convincing confidence argument for a given step of the main argument, we cannot trust its validity.

Example of safety and process reliability argument branches

The argument map diagram below presents this approach applied to a simple assurance case. The argument map shows the pages of the argument diagrams. The top claim name for each page is displayed. The left part of the diagram contains the main safety argument and the confidence argument is shown on the right. You can also browse this assurance case online in PREMIS using this link.

The confidence argument presented here includes just five claims, which is sufficient to demonstrate its structure. It should be based directly on the system development process or its life cycle. The confidence argument should follow the development process and at same time it should be consistent with the structure of the main safety argument. An adequate confidence claim should be provided for each step of the main argument. In practice, there will be hundreds of confidence claims and links to the safety argument. While the use of quality gates and other checkpoints implemented in the safety assurance process can simplify the linking of two arguments, the confidence argumentation must still cover all the requirements of the relevant standards for the development process.

This approach can be extended with additional layers of the argument. For example MISRA Guidelines for Automotive Safety Arguments proposed the next argument layer named Organizational environment that should contain an argument demonstrating that all system life cycle activities are performed by an organization with an appropriate environment, which includes, among others, a Quality Management System (QMS), continuous improvement process, adequate team qualifications.

Separating the argument layers into different argument branches or separate argument modules can make managing large assurance cases easier for development, reviews and maintenance. The relations between the main argument and the layers of the confidence argument are easy to maintain in PREMIS when the structure of the main argument is consistent with the system development process.

Artykuł Using confidence arguments in assurance cases pochodzi z serwisu Argevide.

SPI indicators in dynamic assurance cases

Andrzej Wardziński — Wed, 10 Sep 2025 12:51:35 +0000

Assurance cases are used not only during system development but also during operation. For many systems, Safety Performance Indicators (SPIs) are used in this context. They are used to monitor and report the system safety performance over time. They help to identify whether safety goals are being achieved and provide early warning signals of emerging risks. They are also useful in identifying weaknesses in the safety management system.

Assurance cases should not ignore SPIs, as they provide essential information about the system safety during its operation. However the nature of these indicators is different from regular assurance case evidence. SPI values change over time, so the argument must be able to handle this variability. We need dynamic assurance cases that can react to changes of the reported SPI.

Assurance case process to incorporate SPI data

There are three steps of this process that can be performed automatically:

Transfer the SPI data. The goal is to connect to the SPI measurement system and transfer SPI data into evidence references in the assurance case. SPI data is maintained as dynamic evidence within the argument. This means that data in the argument can be updated daily or more frequently when needed. We use a simple generic data format for SPI values in PREMIS that can represent any type of values, including textual and numerical information.
Interpret the SPI data. This is done by updating the base claim based on the supported SPI evidence. PREMIS allows to define conditions on SPI values to determine the resulting claim assessment. There are three possible statuses for SPI indicators: the SPI status can be OK (acceptable risk level), Warning (risk soon) and Alert (at risk).
Propagate the SPI status information. PREMIS assessment propagation mechanism automatically updates the assessment in the assurance case. Depending on the argument structure, changes of the SPI indicators values may affect the assessment of related claims in the argument, including the top claim. Exceeding the threshold of a single critical SPI indicator may even result in the top claim being rejected.

This process is fully automated when PREMIS arguments are connected to source systems that provide SPI values. This could be a single system integrating all SPIs, or it could be multiple source systems reporting individual metrics. It could be any system that provides network access to its data (an API) or has the ability to transmit the data in any other way, for example by email. We use Jira integrated with PREMIS as the main source of SPI data.

Dynamic evidence, such as SPIs, changes the way arguments are handled. The point is that, most of the time, dynamic evidence works like regular evidence, but it can occasionally turn into counter-evidence. This happens when the indicator’s value indicates that some security requirements are not met. The system’s safety or security argument can only be accepted if the measurement data confirms that the system actually meets the safety and security goals. When a dynamic proof indicates that this is not the case, a response is required, not by changing the argument, as is the case with defeaters, but by changing the value of the evidence – in this case, the SPI indicator. It’s the system operation that needs to be corrected. The argument needs any changes only when the system or the operation process is modified. If the correction involves design changes or the release of a new system version, the relevant parts of the argument should also be updated. Regardless of the associated argumentation changes, it is essential that the dynamic evidence reverts to its accepted state, so that it no longer acts as counter-evidence.

How does it work in practice?

A simple example of a Safety Performance Indicator is the number of open safety issues in Jira. We can have an epic in Jira for collecting safety issues in one place, or a filter to select issues covered by the indicator. Let’s say we have a safety epic and all safety issues should be linked to it as sub-issues. Some issues may not be relevant and we define the SPI as a number of open security issues with major or critical priority. If the indicator value exceeds zero, it should report an ALARM. This can be represented by the following rules in PREMIS:

In some cases we may want to add a WARNING state to be used when the indicator value is close to the limit, but the limit is not exceeded yet.

Depending on the settings of your assurance case the result of the SPI value verification can affect the status of the supported base claim and other claims up the argument structure to the top claim. The diagram below shows an example where the SPI measurement implemented as argument evidence resulted in a WARNING status of the supported base claim, which is then propagated up to the top claim. The top claim can only be accepted when all SPI indicators report the status OK.

Although assurance cases are not intended for tracking safety issues and managing their resolution, they should maintain the current status of system safety. Assurance cases are live artefacts, and one aspect of this involves the use of dynamic evidence, such as performance indicators.

PREMIS supports dynamic evidence, including SPI reporting where you can define rules and conditions when an alarm, a warning or the OK status should be reported.

Contact us if you have questions or want more information how they could be used in your assurance cases.

Artykuł SPI indicators in dynamic assurance cases pochodzi z serwisu Argevide.

Building strong assurance cases

Andrzej Wardziński — Fri, 01 Aug 2025 10:46:02 +0000

Strong assurance cases are achieved by building confidence in the validity of reasoning steps and demonstrating how defeaters are handled. These two approaches present two different directions of argumentation. The first one focuses on providing sound basis for the argument while the second aims at defending it against known defeaters.

Which approach is more effective and should be used? The explicit specification of defeaters seems attractive because it provides direct answers our doubts. When I have a “but…” comment, someone can point to a corresponding defeater in the argument and present how it is handled. In this way an assurance case can address the concerns of doubters. They can be satisfied when they find direct answers for their doubts.

On the other hand handling defeaters creates additional explanations for the argument, which should be sound in the first place. If the argument is weak, the response to a defeater should involve a modification of the argument structure. To avoid this we should develop sound arguments from the outset. The best way is to base on proven argument templates and ensure validity of all reasoning steps. The goal is to avoid weaknesses in the whole argument development process.

There are some basic rules that help in the development of sound arguments.

Specify a strategy for each reasoning step, avoid direct supporting claims by subclaims. This will help reviewers to check if the argument decomposition is complete and valid.
Specify a justification why you think the strategy is valid for a given claim in its context. Is it valid in all application scenarios? Have you considered all interactions? Are all subclaims valid in the main claim context? Identify all possible weaknesses. The justification is especially important when you reuse argument structures in a new context.
When the justification is not straightforward, extend it with a confidence argument.

A confidence argument is an argument that supports the credibility of the main assurance argument. The two arguments form an inseparable pair and should be kept together in one assurance case module. This helps to ensure consistency of argument. An argument module can have one or more confidence top claims. The diagram below presents the general schema for the use of conformance argument. Conformance claim CA1 is used to support strategy S1 in the main assurance argument.

The confidence argument for a reasoning step should justify the validity of the reasoning, taking into account the conditions:

The inference rule is valid for a given claim within its context.
The inference rule has been applied correctly and it covers the full required context.
The premises (sub-claims) are correctly defined and satisfy all conditions.
The premises are valid and consistent.
There no unresolved defeaters or rebuttals.

Explicitly specifying strategies and justifications helps to identify weak reasoning early on. Although it may seem to slow down the development process, detecting argument deficiencies enables the argument structure to be adapted early on in the system assurance process. Confidence argument reviews, involving third-party reviewers when possible, are a good system assurance process practice.

You can read more about the use of confidence argument in the paper “Integrating Confidence and Assurance Arguments” published in 2015. The main idea of the confidence argument is still valid.

Artykuł Building strong assurance cases pochodzi z serwisu Argevide.

Static and dynamic evidence in PREMIS

Andrzej Wardziński — Mon, 30 Jun 2025 11:31:32 +0000

An assurance case is a structured argument supported by evidence. It can a static safety case referring to static evidence and frozen in a Safety Case Report. And it can a dynamic object referring to dynamic evidence that can evolve. For example the evidence may include Safety Performance Indicators based on measurements during system operation. The key question is how you track the changes of evidence to maintain a valid, consistent and up to date dynamic assurance case.

PREMIS supports four ways in which you can refer to evidence within your assurance case. Each method offers the possibility of creating dynamic assurance cases, but with different levels of automation and technical difficulty.

These four ways are given below and they are presented in the video.

You can refer to off-line evidence. The evidence will not be available in the application for the user, but you may specify its identification data or summary. This option does not support dynamic arguments unless you manually change the evidence data or you have a software agent that can do this for you.
You can upload evidence files to PREMIS and use them in the argument. This option also does not support dynamic arguments unless you manually upload new evidence or you have a software agent that can do this for you.
URL addresses can be used to reference to online evidence items. These are usually static objects, such as PDF files, however you can also use web service addresses for dynamic data.
The last option is an integrated evidence repository. This can be a SharePoint service for storing technical documentation but this approach can also be used for repositories containing dynamic data. What’s important, this integration includes authentication. This is often required to access sensitive data in any system.

The first step for building dynamic assurance case is to decide how you plan to transfer the dynamic data into the argument. This will depend on the technology used to produce the data, if the result is available online, what type of authentication is required, or maybe your systems can send some notifications?

The next step is the decision how these data are presented in your argument. You will probably have argument claims referring to system operation and maintenance process (for example in SOTIF).

The final design step involves planning information propagation and notifications. The information propagation in the argument is usually based on the assessment mechanism and this allows to affect the top claim when major problems are reported in the dynamic data. The results can also be published in online bulletins or reports, or via email notifications.

A dynamic assurance case could be an effective tool for supporting system safety or reliability monitoring. However, all this depends on the first step, which is the decision on how dynamic data is to be presented as evidence in the argument. Any solution that works is a good one.

Artykuł Static and dynamic evidence in PREMIS pochodzi z serwisu Argevide.

Easier GSN argument development

Andrzej Wardziński — Sat, 14 Jun 2025 04:33:16 +0000

Editing GSN arguments in PREMIS is now easier, you can drag elements from the tray directly to the diagram. At the same time, the performance of GSN diagrams in the new version of PREMIS has been improved. Especially generating diagrams is now very fast. The new version also includes improvements in the management of assessments, permissions and evidence repositories.

PREMIS version 1.7 was released on 12 June. The most notable improvement is the enhanced performance of GSN diagrams, which has increased by more than twofold. In particular, diagrams can now be generated for existing arguments very quickly.

Another change that makes working with GSN diagrams easier is the introduction of a container of elements that can be dragged directly onto the argumentation diagram. PREMIS ensures that the argument structure complies with the GSN Standard and indicates where a given new element can be inserted. This is shown by the colour of elements in the diagram. Their background turns green when a new element can be inserted. Red colour indicates that a new element cannot be added in that place.

Other improvements in the new PREMIS version include new features in the folder view, including managing user roles in projects and folders and configuring the assessment method. These features are now also available in the module diagram.

It is now also easier to use internal repositories for storing evidence used in assurance case arguments. A new repository can be created directly in the GSN diagram, and then evidence files can be uploaded into the PREMIS server directly in evidence reference elements (GSN Solutions).

Another useful feature is the presentation of evidence in graphic format directly in the GSN diagram. This is useful when, for example, photos taken during inspections are used as evidence. Graphic files are now also included in the reporting data and can be presented directly in Safety Case Reports.

Artykuł Easier GSN argument development pochodzi z serwisu Argevide.

GSN and SACM modular assurance cases

Andrzej Wardziński — Mon, 02 Jun 2025 15:30:22 +0000

Both the GSN Community Standard and OMG SACM specify modular assurance cases, though from different perspectives. The GSN Standard focuses on the logical dependencies between elements in different argument modules. SACM, on the other hand, introduces the concepts of interfaces and bindings in its metamodel. In practice there are no conflicts between the two standards. Both perspectives of modular assurance cases are combined in PREMIS.

The two main characteristic elements defined in these two standard are:

Three types of inter-module relationships defined in GSN: away elements, supported by modules and supported by contracts. GSN describes their properties and graphical notation.
Interfaces and bindings in SACM metamodel allow to technically describe inter-module relationships in a machine-readable form.

First, we will look at GSN and its three types of relations between elements in different argument modules. They are presented in the diagram:

Away element – this is simply a link to an element in the supporting module. This type of relationship offers the least control. The supporting element is only referenced in your module only. It’s not a real element in your module and you cannot modify it. Its fully managed by the owner of the supporting module.
Supported by another module – the element in your argument is supported by another element in a supporting module. This is a standard “supported by” relation used in GSN Standard. This gives some control over the relationship, but there is still no way to verify it.
Supported by a contract – a claim in one module is supported by a claim in another module through an intermediary contract. A contract is a reasoning step inside the connection between the bound modules verification is required whether the supporting claim is sufficient to justify the supported claim in its full context. Contracts are always used for claims together with their applicable context. This type of relationship offers full control over the binding.

GSN defines these relationships as occurring directly between elements in different modules. Each relationship is an independent of the others. This perspective of independent relationships is characteristic of the GSN Standard. An example is presented in the diagram below.

The representation of relationships in SACM is a bit more complex. SACM defines an argument metamodel that can allow to define any type of relationship between modules. To do this effectively SACM introduces two concepts:

An interface is a collection of argument elements that are exposed to other modules (known as ‘packages’ in SACM) in order to establish relationships. This is an important property of SACM – you can expose an argument element on an interface to allow argument developers of other assurance case modules to refer to it.
A binding is a SACM relation between elements exposed in different interfaces. The SACM metamodel is flexible and it enables the binding to model any of the three types of intermodule relations specified by the GSN Standard.

The diagram below presents a simplified view of the SACM representation of relationships between argument modules. Interfaces belong to argument modules and contain references to their elements (citations in SACM terminology). Bindings connect elements from different interfaces.

In order to implement the GSN modules fully in SACM, we have extended the SACM metamodel with additional attributes to assign interface types. Interfaces are divided into ‘provided’ and ‘required’ interfaces. Provided interfaces are used to publish argument elements that support other modules. Required interfaces contain argument elements that must be supported by other modules. These are further divided into three types: away elements, elements supported by a module, and elements supported by a contract. The consequence is that different types of GSN relationships cannot be mixed in one interface.

You can browse a sample modular argument in PREMIS. You have GSN relationships in the user interface and SACM model underneath.

Artykuł GSN and SACM modular assurance cases pochodzi z serwisu Argevide.

Safety and security co-assurance

Andrzej Wardziński — Sat, 17 May 2025 19:25:15 +0000

Both system safety and security are critical goals, but they are not always compatible. You have to consider safety – security relations when developing a system assurance case. A solution to this problem, a Safety-Security Assurance Framework (SSAF), has been proposed by the latest publication of the SCSC Security Informed Safety Working Group. The main idea is to explicitly specify synchronization points between safety and security assurance.

SSAF framework covers technical and socio-technical risks related to safety and security in the whole system life cycle. It’s a broad topic and we will focus on assurance cases. Shorty, the guidance recommends developing three argument legs in the system assurance case: one that considers safety risk, one that considers security risk, and one that considers the risks of their interactions. The diagram below, derived from the SCSC document, illustrates this concept of a Safety-Security Co-Assurance Case.

All branches of the argument are supported by evidence demonstrating requirements satisfaction. There are three sets of requirements: those supporting system safety, system security and safety-security co-assurance. These requirements are created at each phase of the system life cycle, from the concept phase, through design, implementation, testing to the operation. Regardless of the system life cycle used, each phase must include safety and security synchronization. In each phase of the life cycle, activities are performed according to the following steps:

1. Planning including establishing the shared context, terminology and synchronization points. It’s not necessary to agree on the complete context and terminology of safety and security, but on shared elements only.

2. Engineering actions specific for a given phase performed separately for safety and security, exchanging risk related information at agreed synchronization points.

3. Development of the assurance case argument increment for the implemented phase actions separately for safety and security.

4. Development of the co-assurance argument and completing safety and security synchronization for a given phase in the system life cycle. This includes verification and validation of the phase results.

5. Co-assurance impact propagation. Update of the safety and security models, artefacts and goals based on the synchronization results. The co-assurance argument is also updated accordingly.

The process should be performed according to six SSAF Core Principles that ensure development of clear and convincing safety and security co-assurance argument. One of the Core Principles says that explicit synchronization points are to be defined to support interdependent safety and security co-assurance. This is the key point. All interdependencies are to be explicitly specified and managed in the co-assurance argument.

The framework proposed by SCSC is pragmatic and offers great chances for effective safety and security co-assurance. Safety and security engineers work independently in their areas and communicate with each other at specific synchronization points in each phase of the system life cycle. The synchronization results are documented in the co-assurance argument. The success of the entire project depends on the way the synchronization is organized and on the cooperation of involved parties. The adopted principle of explicit specification or safety and security interdependencies offers great chances for the effectiveness of the approach in practice.

You will find full description of Safety-Security Assurance Framework (SSAF) in SCSC document “Through-Life Co-Assurance of System Safety and Cyber Security” (SCSC-173).

Artykuł Safety and security co-assurance pochodzi z serwisu Argevide.