2023 - Argevide

System Assurance Reference Model at PRDC conference

Andrzej Wardziński — Fri, 06 Oct 2023 07:53:40 +0000

We will participate in 28th IEEE Pacific Rim International Symposium on Dependable Computing (PRDC 2023) in Singapore on 24-27 October. We will present our paper on System Assurance Reference Model (SARM). Join us at the conference to enjoy the event and learn more how reference model can improve generation and management of modular assurance case.

The objective of SARM is to manage references in modular assurance case templates to system context models. The models can define system architecture, risk models (including safety and security), environment, conditions of the use and life cycle processes.

SARM enables implementation of argument patterns parameters. GSN standard allows to use parameters for argument pattern operators however the semantics is not fully described. Therefore we have defined the semantics of the parameters to enable the use of references to system models. This allows to develop modular argument templates parametrized with the system context model. A simple fragment of a template is shown below to present how the parameters are presented in the argument.

SARM conditions are used to specify optionality for argument branches (see G2 and G3 in the diagram above). Multiplicity is implemented with model dependences, e.g. G4 will be generated for each subcomponent of C. Model dependencies can also be used to specify argument modules. This allows to generate modular assurance cases consistent with the system model.

In addition the generated argument modules and elements can maintain URL links to the referred model objects. This enables easy navigation from the argument to system models.

You will find more details about SARM in our paper and our presentation at PRDC conference.

Artykuł System Assurance Reference Model at PRDC conference pochodzi z serwisu Argevide.

Warsztaty MASCA na konferencji SAFECOMP

Andrzej Wardziński — Fri, 15 Sep 2023 09:26:33 +0000

Modularność jest skutecznym sposobem zarządzania złożonością assurance case, ale należy ją stosować w uporządkowany i systematyczny sposób, aby uzyskać rzeczywiste korzyści. Temat ten będzie omawiany przez praktyków podczas międzynarodowych warsztatów Modular Argumentation to Support Device Conformity Assessment (MASCA), które odbędą się 19 września podczas konferencji SAFECOMP 2023.

Podczas warsztatu prezentowane będą praktyczne doświadczenia w stosowaniu modularnych argumentacji. uczestnicy będą dyskutować:

Jakie problemy można rozwiązać za pomocą modularnych argumentacji?
Jakie informacje powinny być przekazywane pomiędzy modułami? (np. informacje kontekstowe, znaczniki czasu, kontekst użycia)
Jakie są kryteria przydatności i kompletności kontraktów stosowanych w interfejsach modułów?
Jakie są kryteria oceny, czy warunki kontraktu dla interfejsu zostały spełnione?

Dyskusja będzie oparta na doświadczeniach w zakresie zapewnienia bezpieczeństwa urządzeń medycznych oraz autonomicznych systemów transportu wodnego.

Więcej informacji o workshopie można znaleźć na stronie: https://sites.google.com/view/masca2023/program

Workshop jest organizowany w ramach konferencji SAFECOMP 2023.

Artykuł Warsztaty MASCA na konferencji SAFECOMP pochodzi z serwisu Argevide.

Modular assurance cases on MASCA workshop

Andrzej Wardziński — Fri, 15 Sep 2023 09:26:16 +0000

Modularity is an effective way of managing assurance case complexity, but is should be used in a systematic way to get benefits. This will be discussed by practitioners at the International Workshop on Modular Argumentation to Support Device Conformity Assessment (MASCA) which will be held on 19 September at SAFECOMP 2023 conference.

The current state of the art and practical experiences will be presented during the workshop and the participants will discuss:

What are the problems that might be solved using modular argumentation?
What information should be conveyed between modules? (e.g. context information, time stamp, intended use)
What are the criteria for relevance and completeness of the contracts to connect modules?
What are the criteria for assessing if the contract has been satisfied?

The discussion will be based on the experience of safety and security assurance for medical devices and autonomous waterborne transport systems.

To learn more about the workshop please visit is website: https://sites.google.com/view/masca2023/program

The event is part of the SAFECOMP 2023 conference.

Artykuł Modular assurance cases on MASCA workshop pochodzi z serwisu Argevide.

Kontrakty w assurance case

Andrzej Wardziński — Thu, 27 Jul 2023 13:05:40 +0000

Moduły assurance case można łączyć za pomocą interfejsów. Standard GSN w wersji 3 definiuje trzy rodzaje interfejsów:

obcy element (cytowanie),
wsparcie przez moduł,
wsparcie przez kontrakt.

W naszym majowym poście zaprezentowaliśmy diagram porównujący typy interfejsów, ale przedstawiony tam schemat był zbyt uproszczony. Brakowało ważnej cechy kontraktów. Aby to skorygować, zaktualizowaliśmy ten diagram. Dodaliśmy symbol kontraktu pomiędzy modułami oraz dodatkowo ikony ocen.

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.

Kontrakt argumentacji jest ważny, gdy postulat opublikowany w jednym module wspiera postulat w innym module w pełnym jego kontekście. Gdy ten warunek nie jest spełniony, kontrakt staje się nieważny. Status kontraktu prezentowany jest w NOR-STA za pomocą oceny.

Kontrakt, który nie został jeszcze zweryfikowany, ma status „nieznany” i żółtą ikonę oceny.
Gdy kontrakt zostanie zweryfikowany i zaakceptowany, ikona oceny otrzymuje kolor zielony. Oznacza to, że kontrakt jest ważny, a moduły są skutecznie powiązane.
Brak weryfikacji kontaktu powoduje jego odrzucenie. Ikona staje się czerwona, a kontrakt jest nieważna.

Moduły uważa się za połączone tylko wtedy, gdy kontrakt został zweryfikowany i potwierdzono, że jest ważny.

Kontrakty są narzędziem do kontrolowania powiązań modułów. Przede wszystkim powiązanie modułów nie jest automatyczne, a wymaga weryfikacji kontraktu. Dodatkowo w przypadku modyfikacji któregokolwiek z powiązanych postulatów kontrakt automatycznie staje się nieaktualny i wymaga ponownej weryfikacji.

Weryfikacja kontraktu opiera się na prostym wzorcu z dwoma postulatami powiązanymi poprzez element strategii. Dla obu postulatów powinny być określone powiązane elementy kontekstu i założenia.

Wzorzec ten wygląda na prosty, jednak weryfikacja kontekstu może być w niektórych przypadkach trudna. Można to częściowo zautomatyzować, wymieniając odziedziczone elementy kontekstu, gdy są one określone dla postulatów wyższego poziomu. To może zredukować pracę ręcznego sprawdzenia jaki jest dziedziny kontekst. Problemy pojawiają się, gdy kontekst jest określony w opisie postulatu, a nie jako osobny element. Można wtedy łatwo pominąć informacje kontekstowe podczas weryfikacji umowy. Zalecaną praktyką jest określenie pełnego kontekstu postulatów w argumentacji, gdy planowane jest użycie kontraktów w interfejsach.

Osobnym tematem jest porównanie zakresu kontekstu obu powiązanych postulatów. Zwykle jest to łatwe, gdy oba moduły argumentacji są opracowane przez ten sam zespół o odwołują się do tych samych pojęć kontekstowych i dokumentacji. Jednak gdy moduły są rozwijane niezależnie przez różne zespoły, weryfikacja spójności kontekstu może być trudna. Aby uniknąć problemu lub zmniejszyć jego dotkliwość, można uzgodnić kontekst dla każdego modułu argumentacji przed rozpoczęciem jego opracowywania.

Rozwiązaniem opisanego problemu jest zastosowanie współdzielonego modelu kontekstu, który definiuje terminy stosowane we wszystkich powiązanych modułach assurance case. Przykładem takiego modelu może być ODD (Operational design domain), który jest stosowany w przemyśle motoryzacyjnym. Modelowanie kontekstowe to ciekawy temat i będziemy o tym pisać w jednym z naszych kolejnych wpisów.

Artykuł Kontrakty w assurance case pochodzi z serwisu Argevide.

Assurance case contracts

Andrzej Wardziński — Thu, 27 Jul 2023 13:05:11 +0000

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.

Artykuł Assurance case contracts pochodzi z serwisu Argevide.

Tekstowa a graficzna reprezentacja assurance case

Andrzej Wardziński — Fri, 30 Jun 2023 06:14:49 +0000

Zwykle assurance case są prezentowane w formie diagramów, na przykład GSN lub CAE. Jest to jest forma prezentacji wygodna podczas zapoznawania się z daną argumentacją. Nie jest to jednak jedyny sposób prezentacji. Możliwa jest też prezentacja argumentacji w formie tekstowej oraz tabelarycznej. Formę tekstową stosujemy w NOR-STA od ponad 10 lat. Porównamy jej stosowanie do formy graficznej oraz pokażemy, że obie formy prezentacji mogą być stosowane w efektywny sposób.

Tekstowa forma prezentacji zakłada stosowanie formatowanego tekstu, w którym wcięcia wierszy określają umiejscowienie elementu w strukturze argumentacji. NOR-STA wspiera formę tekstową dla trzech notacji: GSN, CAE oraz TRUST-IT. Narzędzie automatyzuje stosowanie wcięć i zarządzanie strukturą argumentacji z ich pomocą.

a) GSN c) CAE c) TRUST-IT

Notacja graficzna w NOR-STA jest dostępna tylko dla diagramów GSN. Diagram zgodny ze standardem GSN obejmujący podstawowe typy elementów argumentacji jest przedstawiony poniżej.

Prezentacja argumentacji innym użytkownikom: Graficzna forma prezentacji ułatwia poznanie zawartości argumentacji przez nowe osoby. Śledzenie relacji pokazanych przez strzałki jest proste. Duże argumentacje można dzielić na strony, co może być przydatne, szczególnie gdy diagramy mają być drukowane i dołączane do dokumentów. Wtedy pomocny w nawigacji jest też diagram mapy stron (w NOR-STA jest generowany automatycznie).

Edycja argumentacji: Tekstowa forma argumentacji sprawia, że można koncentrować się na zawartości argumentacji, zamiast na jej układzie graficznym. Struktura elementów jest zarządzana automatycznie przez aplikację, dzięki czemu dodanie lub usunięcie elementu nie wymaga przesuwania innych elementów.

W widoku graficznym nawet zmiana długości nazwy elementu może powodować potrzebę przebudowy układu diagramu. W reprezentacji tekstowej edycja jest łatwiejsza, bo użytkownik nie musi zajmować się układem diagramu

Zarządzanie dowodami, interfejsami i informacjami kontekstowymi: Informacje tego typu są łatwiejsze do zarządzania w formie tekstowej (jako listy elementów) lub w formie tabelarycznej. Pracujemy obecnie nad wypracowaniem jednolitej formy tekstowej pozwalającej zarządzać kontekstem modułu argumentacji, jego interfejsami oraz dowodami. Więcej na ten temat napiszemy w jednym z przyszłych wpisów.

Automatyzacja argumentacji: Stosujemy narzędzia generujące nowe moduły argumentacji i bardziej naturalnym rozwiązaniem jest tu stosowanie formy tekstowej. Informacje o układzie graficznym elementów mogą zostać dodane w późniejszych krokach, gdy będzie potrzebna wizualna prezentacja argumentacji dla użytkowników

Bazując na doświadczeniach użytkowników możemy powiedzieć, że tekstowa forma prezentacji argumentacji jest skuteczna podczas rozwoju argumentacji, szczególnie podczas pracy z dużymi modułami. Natomiast forma graficzna jest doskonała do prezentowania argumentacji dla innych osób, w tym oceniających i zatwierdzających assurance case. Wszyscy mamy tendencję do myślenia wizualnego, więc forma graficzna jest łatwiejsza dla początkujących. Obie formy, graficzna i tekstowa, są użyteczne i żadna z nich nie jest zbędna.

Argumentacja to główny, ale nie jedyny element assurance case. Pozostałe rodzaje informacji także są pokazywane na diagramach, ale inne formy prezentacji sprawdzają się lepiej przy zarządzaniu nimi. Zarządzanie dowodami jest zwykle realizowane w repozytoriach. Przykładowo, argumentacja w NOR-STA może być powiązana z folderem repozytorium SharePoint. Każdy z rodzajów informacji w assurance case, pokazanych na diagramie poniżej, wymaga trochę innego podejścia i innej formy prezentacji.

Będziemy pisać o pracy z poszczególnymi rodzajami informacji assurance case w naszych przyszłych wpisach.

Artykuł Tekstowa a graficzna reprezentacja assurance case pochodzi z serwisu Argevide.

Textual vs graphical representation of assurance cases

Andrzej Wardziński — Fri, 30 Jun 2023 06:14:31 +0000

Assurance cases are usually presented in the form of diagrams, for example GSN or CAE. This is a convenient form of presenting the argument to others and familiarizing yourself with its content. However it is not the only way to present assurance cases. Another method is to use the textual or tabular form. We have been using the textual form for over 10 years in NOR-STA. We will shorty compare and comment on the application of the textual and the graphical form of assurance case presentation.

In NOR-STA we use hierarchical textual form to present the argument structure. Every element is in a separate line and the line indentation determines its position in the argument structure. NOR-STA supports the hierarchical textual form for three argument notations: GSN, CAE and TRUST-IT. The tool automates the use of indentation to present the structure of the argument.

a) GSN c) CAE c) TRUST-IT

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.

Presenting the argument to other users: The graphical form of the presentation makes it easier for new people to learn the content of the assurance case. Keeping track of the relations shown by arrows is simple.

Large arguments can be divided into pages, which is useful when the diagrams are to be printed and included in documents. In such case a page map diagram can be created for easier navigation (in NOR-STA it is automatically generated).

Argument editing: The textual form makes it possible to focus on the content of the argument, instead of its layout. The argument structure is managed automatically by the application therefore adding or removing argument elements does not require any additional actions to adjust the diagram layout and move other items.

In the graphical view, even changing the length of the element’s name may cause the need to rebuild the diagram’s layout. In the textual representation, editing is simpler since the user does not need to be concerned with the diagram’s layout.

Managing evidence, interfaces and contextual information: These types of information are easier to manage in textual form (as a list of items) or in tabular form. We are currently working on developing a uniform textual form for managing the context of the argumentation module, its interfaces and evidence. We will write more about this in one of the next posts.

Argument automation: We develop and use other tools that generate new argumentation modules and the natural solution of doing this is using the textual form. Information about the graphical layout can be added in later steps when the visual presentation of the argument is needed for users.

Based on the user experience, we can say that the text form of argument presentation is effective during argument development, especially when working with large module. The graphical form, on the other hand, is perfect for presenting arguments to others, including those evaluating and approving assurance cases. We all tend to think visually and the graphical form is easier for beginners. Both forms, graphical and textual, are useful and neither is redundant.

Argumentation is the main, but not the only element of the assurance case. Other types of information are also shown in diagrams, but other forms of presentation are better for managing them. Evidence management is typically done in repositories. For example an argumentation in NOR-STA can be related to a SharePoint repository folder. Each type of information in an assurance case, which are shown in the diagram below, requires a specific approach and a different form of presentation.

We will write about working with particular types of assurance case information in our next posts.

Artykuł Textual vs graphical representation of assurance cases pochodzi z serwisu Argevide.

Modularne assurance case w NOR-STA

Andrzej Wardziński — Tue, 02 May 2023 05:00:24 +0000

Modularyzacja jest przydatna w zarządzaniu dużymi i złożonymi argumentacjami assurance case. Pozwala na rozdzielenie odpowiedzialności za moduły oraz na zarządzanie uprawnieniami na poziomie poszczególnych modułów.

NOR-STA implementuje model argumentacji assurance case oparty o OMG SACM, który został rozszerzony dla implementacji trzech rodzajów powiązań zdefiniowanych w standardzie GSN.

Podział argumentacji na moduły umożliwia stosowanie diagramów modułowych dla prezentacji architektury assurance case. Poszczególne moduły mogą odpowiadać różnym komponentom lub funkcjom systemu, hazardom, zagrożeniom security, standardom lub innych właściwościom.

Podział argumentacji na moduły jest zwykle wykonywane w postulatach. Dowolny postulat może zostać określony jako element interfejsu między modułami. Widoczna na diagramie relacja wsparcia modułów jest w rzeczywistości relacją wsparcia pomiędzy postulatami. Kierunek strzałki określa relację ‘jest wspierany przez’ zgodnie z zasadami w GSN.

Powyższy diagram architektury przedstawia trzy moduły. Moduł nadrzędny opisuje obniżenie ryzyka hazardu. Dwa kolejne moduły zapewniają argumentację jak dwa komponenty wspierają to obniżenie ryzyka hazardu. Każdy z tych modułów może być niezależnie rozwijany.

Punktami połączenia pomiędzy modułami są postulaty. Jest to widoczne na kolejnym diagramie. Dwa postulaty w nadrzędnym module mają dodatkowe ikony modułu oraz nazwy wspierających modułów. Są one nazywane elementami zewnętrznymi (away elements) zgodnie z GSN. Są one po prostu linkami do postulatów w innych modułach.

Łączenie modułów może wyglądać na proste, ale zaimplementowany model formalny jest całkiem złożony. Po pierwsze należy odróżnić dwie role połączonych postulatów. Niektóre z nich wymagają wsparcia, a inne dostarczają wsparcie. Dwa postulaty w module nadrzędnym wymagają wsparcia, a główne postulaty modułów komponentów dostarczają wsparcie.

Kolejnym krokiem jest grupowanie postulatów w interfejsach. Interfejs to jest pojemnik na elementy argumentacji (postulaty) udostępniane dla innych modułów. Rozróżniamy dwa rodzaje interfejsów:

Interfejs wymagany zawiera postulaty, dla których wsparcie mają zapewnić inne moduły argumentacji.
Interfejs dostarczany zawiera postulaty, które dostarczają wsparcie dla innych modułów.

Nie jest dozwolone mieszanie postulatów wymaganych i dostarczanych w jednym interfejsie w NOR-STA. Osobne interfejsy są stosowane dla postulatów wymaganych, a osobne dla dostarczanych.

Gdy mamy już postulaty w interfejsach, to możemy je powiązać. Powiązanie to połącznie, które działa na dwóch poziomach:

Powiązanie interfejsów łączy interfejs wymagany z interfejsem dostarczanym w innym module.
Powiązanie elementów łączy dwa elementy (postulaty) będące w interfejsach, gdzie jeden postulat wymaga wsparcia, a drugi je dostarcza.

Diagramy GSN nie pokazują interfejsów. Standard GSN definiuje pojęcie interfejsu modułu (1:4.6) jako zbiór elementów wymaganych i dostarczanych. NOR-STA implementuje trochę bardziej zaawansowany model interfejsów określony przez OMG SACM, który pozwala na tworzenie więcej niż jednego interfejsu, które mogą być udostępniane dla różnych grup odbiorców. Rozszerzymy diagram GSN, aby pokazać na nim interfejsy oraz powiązania. Dodaliśmy też kolejny interfejs dla postulatu G0. To pokazuje, że w NOR-STA definiowane są osobne interfejsy dla elementów wymaganych i dostarczanych. To podejście różni się od standardu GSN, który definiuje tylko jeden interfejs moduły, który obejmuje wszystkie elementy, wymagane i dostarczane

Interfejs może zawierać dowolną liczbę elementów, a w module można utworzyć dowolną liczbę interfejsów. Zarządzanie interfejsami może wyglądać na złożone zadanie, ale często można je ignorować. NOR-STA może automatycznie tworzyć interfejsy, gdy są potrzebne.

Powiązanie elementów pokazane na diagramach powyżej to powiązanie typu ‘element zewnętrzny’ (away element). Sekcja Modular Extension w standardzie GSN określa trzy rodzaje powiązań interfejsów, które są też zaimplementowane w NOR-STA.

Element zewnętrzny (away element) – link do elementu z innego modułu utworzony w bieżącej argumentacji. To działa jako prosty link pomiędzy modułami. Nazwa i opis takiego elementu są pobierane wprost z moduły dostarczającego i nie podlegają edycji. Nazwa modułu na diagramie (patrz element obok) oznacza, że element zewnętrzny jest podłączony. Brak nazwy modułu oznacza brak powiązania.

Wspierany przez inny moduł – element w bieżącym module jest wspierany przez element w innym module. Taki typ powiązania jest sygnalizowany przez ikonkę modułu poniżej elementu postulatu. Gdy element jest powiązany, to obok ikony modułu jest wyświetlany jego symbol.

Wspierany przez kontrakt – element jest wspierany przez inny element w module wspierającym poprzez pośredniczący kontrakt. Kontrakt to jest dedykowany krok wnioskowania stwierdzający, że postulat dostarczany wspiera postulat wymagany z pełnym jego zakresie i kontekście. Celem stosowania kontraktów jest wymuszenie wykonania przez użytkownika przeglądu wszystkich powiązań.

Rozróżnienie trzech typów powiązań jest zgodne z ich definicjami w standardzie GSN Community Standard. Więcej informacji o typach powiązań można znaleźć w sekcji Modular Extension standardu.

Typ powiązania jest wybierany przez użytkownika NOR-STA podczas tworzenia interfejsu wymaganego. Interfejs dostarczany akceptuje powiązania z interfejsów wymaganych różnych typów.

Jak wybrać odpowiedni tym powiązania?

W skrócie:

Jeżeli potrzebujesz po wprost postulat w innego modułu, to użyj ‘elementu zewnętrznego’ (away element). Jego nazwa i opis będą automatycznie odświeżone, gdy ktoś zmieni postulat dostarczany.
Jeżeli potrzebujesz po prostu powiązań dwa postulaty, to użyj powiązania typu wspierany przez moduł. To jest najprostszy sposób na powiązanie postulatów.
Jeżeli potrzebujesz sprawdzenia, czy powiązania są poprawnie zdefiniowane, to wybierz opcję wspierany przez kontrakt. Dla każdego powiązania postulatów będzie wymagane przeprowadzenie przeglądu i ocena.

W tym krótkim tekście jest wiele tematów, które nie zostały omówione, na przykład, jak zarządzać kontekstem w modułowych argumentach i jak upewnić się, że kontekst wspierających modułów pasuje.

Aby dowiedzieć się więcej o stosowaniu modularnych argumentacji w NOR-STA zachęcamy do zajrzenia do podręcznika NOR-STA oraz do udziału w naszym szkoleniu 18 maja.

Artykuł Modularne assurance case w NOR-STA pochodzi z serwisu Argevide.

Modular assurance cases in NOR-STA

admin — Tue, 02 May 2023 05:00:17 +0000

Modularisation is helpful in managing large and complex assurance cases. It also allows to distribute responsibilities and manage access rights on the level of single modules. Modularisation is required to enable reuse of arguments.

NOR-STA implements modular argument metamodel defined in OMG SACM and extends it to implement three types of bindings between argument modules specified in GSN Community Standard.

Splitting an assurance case into modules enables presentation of its architecture using modular diagrams. You can develop separate argument modules for different system components or functions, hazards, threats, standards or other properties.

The breakdown of the argument into modules is usually made in claims. Any claim in the argument may be used as an interface between the modules. The support relation between argument modules presented in the diagram is in fact a support relation between connected claims. We will use GSN diagrams In this text. The direction of the arrow presents the relation ‘is supported by’.

The architecture diagram presents three argument modules. The top one describes mitigation for a hazard. The two others provide the argument how two components support the hazard mitigation. Each module can be developed by an independent team.

The connection points between the modules are claims. This will be presented in the next diagram. The two claims in the top argument with the module icon and a name of the supporting module are called ‘away elements’ according to the GSN terminology. They are links to the corresponding claims in the supporting modules.

Connecting modules may look simple but the implemented formal model is quite complex. First we should distinguish two roles of connected claims. Some of them require to be supported while the others provide support. The two claims in the top module require support. The top claims of two modules SENSOR and VALVE provide support.

The next step is to group these claims in the interfaces. An interface is a container of argument elements (claims) made available for other argument modules for connection. There are two main types of interfaces:

Required interfaces contain unsupported claims which require to be supported by claims in other argument modules.
Provided interfaces contain claims which can provide support for other argument modules.

It is not allowed to mix required claims and provided claims in one interface in NOR-STA. Separate interfaces should be used for claims which require to be supported and for claims which provide support.

When we have claims in the interfaces we can connect then with a binding. A binding is a connection which works on two levels:

Interface binding connects a required interface in one module with a provided interface in another argument module.
Element binding connects two elements (claims) in the interfaces, where one requires to be supported and another one provides the support.

GSN diagrams do not show the interfaces. GSN standard defines a concept of a module interface (1:4.6) as a collection of all required and provided elements together. NOR-STA implements a more advanced concept of interfaces as defined in OMG SACM. This allows creation of more than one interface ahich can be provided for different audiences. We will extend the GSN diagram to present the interfaces and bindings. Note that we have also added a new interface with the claim G0 to present that we use separate required interfaces and separate provide interfaces. The difference between NOR-STA and the GSN standard is that the GSN standard defines one interface to contain all required and public elements and in NOR-STA there are separate interfaces.

An interface can include more then one element of the argument. You can create any number of interfaces. Managing the interfaces and bindings may seem to be complex task but in practice you can often ignore them. NOR-STA can create the interfaces automatically when necessary.

The connection between claims presented in the diagrams above is of a type called ‘away element’. There are three types of connections defined in GSN and implemented in NOR-STA.

Away element – a citation of an element in another module will be created in your argument. This is simply a link to a claim in the supporting module. You will not be able to edit the name nor the description of an away element as they are taken directly for another module. If the module symbol is empty it means that there is no binding and that the element waits to be linked to the supporting module

Supported by another module – the element in your argument is supported by another element in a supporting module. This type of connection is represented by a module icon decorator below the element. When the element is supported by another module then its symbol is printed next to the module icon.

Supported by a contract – the binding is automatically extended with a dedicated step of reasoning called a contract. The contract says that the supporting claim is sufficient to justify the supported claim in its full context. The objective of the use of contracts if to force the user to review every binding.

The distinction of three types of bindings between argument modules is compliant with GSN Community Standard. Please refer to Modular Extension in GSN Standards for more information about the types of bindings.

The type of the binding is to be chosen by the NOR-STA user at the time when the required interface is created. The provided interface can accept any type of the binding.

How to choose the type of the binding for the required interface?

If you need a link to a claim in another module please select away element. The name and the description from the source argument will be presented. When the provided claim is modified you will automatically see its current name and description.
If you need to connect two claims you should choose the option supported by another module. The binding of this type creates an ‘is supported’ relation between two claims in different argument modules. This is the simplest way to connect two claims.
Choose the last option (supported by a contract) when you need verification of the binding. A simple contract argument will be created automatically for each binding and it can be available for the assessment. Each binding will need individual review and conformation by the user that it is valid.

There are many topics not covered in this short text, for example how to manage context in modular arguments and how to make sure that the context of a supporting modules fits.

To learn more about modular assurance cases in NOR-STA refer to NOR-STA manual or join our online training on the 18th of May.

Artykuł Modular assurance cases in NOR-STA pochodzi z serwisu Argevide.

Warsztaty MASCA na konferencji SAFECOMP 2023

Andrzej Wardziński — Fri, 21 Apr 2023 09:26:20 +0000

Argevide jest zaagażowana w organizację międzynarodowych warsztatów Modular Argumentation to Support Device Conformity Assessment (MASCA), które odbędą się 19 września podczas konferencji SAFECOMP.

Wraz ze wzrostem złożoności systemów, również zadania związane z zapewnieniem bezpieczeństwa stają się coraz bardziej złożone i czasochłonne. Jednym ze sposobów sprostania temu wyzwaniu jest modularyzacja assurance case. Wprowadzenie modułowości od etapu projektowania do certyfikacji znacznie zmniejsza pracochłonność prac oraz pozwala na ponowne wykorzystanie już sprawdzonej argumentacji uzasadniającej zapewnienie (w tym odpowiednich dowodów).

Warsztaty MASCA skupią się na zapewnianiu bezpieczeństwa systemów oraz sposobach zarządzania modułowymi assurance case. Warsztaty stworzą forum do prezentacji tematycznych i dogłębnych dyskusji na temat strukturyzacji, wzorców, ponownego wykorzystania oraz łączenia assurance case oraz dowodów atestacyjnych.

Warsztaty będą koncentrować się na obszarze urządzeń medycznych, ale obejmą również inne dziedziny, takie jak transport, automatyka przemysłowa, robotyka, energetyka jądrowa i obronność.

Więcej informacji znajdziesz w ogłoszeniu warsztatów oraz na stronie konferencji SAFECOMP.

Artykuł Warsztaty MASCA na konferencji SAFECOMP 2023 pochodzi z serwisu Argevide.