-
Notifications
You must be signed in to change notification settings - Fork 6
RACK Cookbook
This cookbook aims to provide a common usage guide for the RACK data model, so that data providers and data consumers can find common ground in how our model is used. As we work with other ARCOS performers, recipes appropriate to the systems and evidence relevant to the program will be added here.
This recipe recommends how hierarchical structure of systems can be represented. For now, we support a simple tree-structured directed graph of system components and their inclusion in other system components.
Click here to download Recipe 1.
System development is a type of ACTIVITY related to the creation of one or more system components.
Click here to download Recipe 1a.
INTERFACE describes directed connections between a SYSTEM, providing what another SYSTEM requires. Source SYSTEM provides what the INTERFACE offers; destination SYSTEM requires what the INTERFACE offers. The INTERFACE commodity (with values of type string) is the thing conveyed by the INTERFACE.
Click here to download Recipe 1b.
This recipe recommends how test procedure, test steps, and tests are modeled. This recipe also recommends how test log, test records, and test results are modeled. The contents of test procedures are test steps, and the contents of test steps are tests. Analogously, the contents of test logs are test records, and the contents of test records are test results.
Test records logs test steps, while test results confirms tests. This is how the two sides link.
Test Execution is a type of ACTIVITY, where test procedure is what was executed.
Test step sequences are specified by nextStep. Analogously, test record sequences are specified by nextRecord.
Finally, test verifies an ENTITY (such as a REQUIREMENT).
Click here to download Recipe 2 (1), (2), (3).
This recipe recommends how low level and high level requirements can be modeled, and includes the notion of requirements specifications.
Click here to download Recipe 3.
This recipe recommends how to structure evidence about structural coverage analysis. The structural coverage ANALYSIS used an executable object FILE and a TEST_PROCEDURE. The ANALYSIS is runBy a test engineer and was analyzedWith a structural analysis tool. The ANALYSIS_OUTPUT wasGeneratedBy the ANALYSIS. The sturctural coverage analysis is on a source code file, which is specified in the analyzes relation of ANALYSIS_OUTPUT.
Click here to download Recipe 4.
This recipe recommends how to model standards documents and verification about compliance to them.
Click here to download Recipe 5.
This recipe recommends how to model hazards and they are mitigated. Additionally, traceability of the hazard can be captured using wasDerivedFrom.
Click here to download Recipe 6.
This recipe recommends how to connect an ENTITY to its MODEL and where that model is used. In this example, the MODELs of REQUIREMENTs that are used for requirement ANALYSIS such as completeness or conflict.
Click here to download Recipe 7.
This recipe recommends how to connect connect DATA_DICTIONARY_TERMs to an ENTITY (such as a REQUIREMENT) that provides it, and also how to connect to an ENTITY that consumes it.
Click here to download Recipe 8.
Copyright (c) 2021-2024, General Electric Company, Galois, Inc.
All Rights Reserved
This material is based upon work supported by the Defense Advanced Research Projects Agency (DARPA) under Contract No. FA8750-20-C-0203.
Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Defense Advanced Research Projects Agency (DARPA).
Distribution Statement "A" (Approved for Public Release, Distribution Unlimited)