forked from Isabelle_DOF/Isabelle_DOF
729 lines
30 KiB
Plaintext
729 lines
30 KiB
Plaintext
chapter \<open>An Outline of a CENELEC Ontology\<close>
|
|
|
|
text\<open> NOTE: An Ontology-Model of a certification standard such as CENELEC or Common Criteria
|
|
identifies:
|
|
- notions (conceptual \emph{categories}) having \emph{instances}
|
|
(similar to classes and objects),
|
|
- their subtype relation (eg., a "SRAC" is an "assumption"),
|
|
- their syntactical structure
|
|
(for the moment: defined by regular expressions describing the
|
|
order of category instances in the overall document as a regular language)
|
|
\<close>
|
|
|
|
(*<<*)
|
|
theory CENELEC_50128
|
|
imports "../Isa_COL"
|
|
begin
|
|
(*>>*)
|
|
|
|
text\<open> Excerpt of the BE EN 50128:2011, page 22. \<close>
|
|
|
|
section\<open>Terms and Definitions\<close>
|
|
|
|
Definition*[assessment::concept]\<open>process of analysis to determine whether software, which may include
|
|
process, documentation, system, subsystem hardware and/or software components, meets the specified
|
|
requirements and to form a judgement as to whether the software is fit for its intended purpose.
|
|
Safety assessment is focused on but not limited to the safety properties of a system.\<close>
|
|
|
|
Definition*[assessor::concept, tag="''assessor''"]
|
|
\<open>entity that carries out an assessment\<close>
|
|
|
|
Definition*[COTS::concept, tag="''commercial off-the-shelf software''"]
|
|
\<open>software defined by market-driven need, commercially available and whose fitness for purpose
|
|
has been demonstrated by a broad spectrum of commercial users\<close>
|
|
|
|
|
|
Definition*[component::concept]
|
|
\<open>a constituent part of software which has well-defined interfaces and behaviour
|
|
with respect to the software architecture and design and fulfils the following
|
|
criteria:
|
|
\<^enum> it is designed according to “Components” (see Table A.20);
|
|
\<^enum> it covers a specific subset of software requirements;
|
|
\<^enum> it is clearly identified and has an independent version inside the
|
|
configuration management system or is a part of a collection of components
|
|
(e. g. subsystems) which have an independent version
|
|
\<close>
|
|
|
|
Definition*[CMGR::concept, tag="''configuration manager''"]
|
|
\<open>entity that is responsible for implementing and carrying out the processes
|
|
for the configuration management of documents, software and related tools including
|
|
\<^emph>\<open>change management\<close>\<close>
|
|
|
|
Definition*[customer::concept]
|
|
\<open>entity which purchases a railway control and protection system including the software\<close>
|
|
|
|
Definition*[designer::concept]
|
|
\<open>entity that analyses and transforms specified requirements into acceptable design solutions
|
|
which have the required safety integrity level\<close>
|
|
|
|
Definition*[entity::concept]
|
|
\<open>person, group or organisation who fulfils a role as defined in this European Standard\<close>
|
|
|
|
declare_reference*[fault::concept]
|
|
Definition*[error::concept]
|
|
\<open>defect, mistake or inaccuracy which could result in failure or in a deviation
|
|
from the intended performance or behaviour (cf @{concept (unchecked) \<open>fault\<close>}))\<close>
|
|
|
|
Definition*[fault::concept]
|
|
\<open>defect, mistake or inaccuracy which could result in failure or in a deviation
|
|
from the intended performance or behaviour (cf @{concept \<open>error\<close>})\<close>
|
|
|
|
Definition*[failure::concept]
|
|
\<open>unacceptable difference between required and observed performance\<close>
|
|
|
|
Definition*[FT::concept, tag="''fault tolerance''"]
|
|
\<open>built-in capability of a system to provide continued correct provision of service as specified,
|
|
in the presence of a limited number of hardware or software faults\<close>
|
|
|
|
Definition*[firmware::concept]
|
|
\<open>software stored in read-only memory or in semi-permanent storage such as flash memory, in a
|
|
way that is functionally independent of applicative software\<close>
|
|
|
|
Definition*[GS::concept,tag="''generic software''"]
|
|
\<open>software which can be used for a variety of installations purely by the provision of
|
|
application-specific data and/or algorithms\<close>
|
|
|
|
Definition*[implementer::concept]
|
|
\<open>entity that transforms specified designs into their physical realisation\<close>
|
|
|
|
Definition*[integration::concept]
|
|
\<open>process of assembling software and/or hardware items, according to the architectural and
|
|
design specification, and testing the integrated unit\<close>
|
|
|
|
Definition*[integrator::concept]
|
|
\<open>entity that carries out software integration\<close>
|
|
|
|
Definition*[PES :: concept, tag="''pre-existing software''"]
|
|
\<open>software developed prior to the application currently in question, including COTS (commercial
|
|
off-the shelf) and open source software\<close>
|
|
|
|
Definition*[OSS :: concept, tag="''open source software''"]
|
|
\<open>source code available to the general public with relaxed or non-existent copyright restrictions\<close>
|
|
|
|
Definition*[PLC::concept, tag="''programmable logic controller''"]
|
|
\<open>solid-state control system which has a user programmable memory for storage of instructions to
|
|
implement specific functions\<close>
|
|
|
|
Definition*[PM::concept, tag="''project management''"]
|
|
\<open>administrative and/or technical conduct of a project, including safety aspects\<close>
|
|
|
|
Definition*[PGMGR::concept, tag="''project manager''"]
|
|
\<open>entity that carries out project management\<close>
|
|
|
|
Definition*[reliability::concept]
|
|
\<open>ability of an item to perform a required function under given conditions for a given period of time\<close>
|
|
|
|
Definition*[robustness::concept]
|
|
\<open>ability of an item to detect and handle abnormal situations\<close>
|
|
|
|
Definition*[RMGR::concept, tag="''requirements manager''"]
|
|
\<open>entity that carries out requirements management\<close>
|
|
|
|
Definition*[RMGMT::concept, tag="''requirements management''"]
|
|
\<open>the process of eliciting, documenting, analysing, prioritising and agreeing on requirements and
|
|
then controlling change and communicating to relevant stakeholders. It is a continuous process
|
|
throughout a project\<close>
|
|
|
|
Definition*[risk::concept]
|
|
\<open>combination of the rate of occurrence of accidents and incidents resulting in harm (caused by
|
|
a hazard) and the degree of severity of that harm\<close>
|
|
|
|
Definition*[safety::concept]
|
|
\<open>freedom from unacceptable levels of risk of harm to people\<close>
|
|
|
|
Definition*[SA::concept, tag="''safety authority''"]
|
|
\<open>body responsible for certifying that safety related software or services comply with relevant
|
|
statutory safety requirements\<close>
|
|
|
|
Definition*[SF::concept, tag="''safety function''"]
|
|
\<open>a function that implements a part or whole of a safety requirement\<close>
|
|
|
|
Definition*[SFRS::concept, tag= "''safety-related software''"]
|
|
\<open>software which performs safety functions\<close>
|
|
|
|
Definition*[software::concept]
|
|
\<open>intellectual creation comprising the programs, procedures, rules, data and any associated
|
|
documentation pertaining to the operation of a system\<close>
|
|
|
|
Definition*[SB::concept, tag="''software baseline''"]
|
|
\<open>complete and consistent set of source code, executable files, configuration files,
|
|
installation scripts and documentation that are needed for a software release. Information about
|
|
compilers, operating systems, preexisting software and dependent tools is stored as part of the
|
|
baseline. This will enable the organisation to software deployment
|
|
transferring, installing and activating a deliverable software baseline that has already been
|
|
released and assessed
|
|
\<close>
|
|
|
|
|
|
|
|
Definition*[SWLC::concept, tag="''software life-cycle''"]
|
|
\<open>those activities occurring during a period of time that starts when
|
|
software is conceived and ends when the software is no longer available for use. The software life
|
|
cycle typically includes a requirements phase, design phase,test phase, integration phase,
|
|
deployment phase and a maintenance phase 3.1.35 software maintainability
|
|
capability of the software to be modified; to correct faults, improve to a different environment
|
|
\<close>
|
|
|
|
Definition*[SM::concept, tag="''software maintenance''"]
|
|
\<open> action, or set of actions, carried out on software after deployment functionality
|
|
performance or other attributes, or adapt it with the aim of enhancing or correcting its\<close>
|
|
|
|
Definition*[SOSIL::concept, tag="''software safety integrity level''"]
|
|
\<open>classification number which determines the techniques and measures that have to be applied to
|
|
software NOTE Safety-related software has been classified into five safety integrity levels, where
|
|
0 is the lowest and 4 the highest.\<close>
|
|
|
|
Definition*[supplier::concept]
|
|
\<open>entity that designs and builds a railway control and protection system including the software
|
|
or parts thereof\<close>
|
|
|
|
Definition*[SYSIL::concept, tag="''system safety integrity level''"]
|
|
\<open>classification number which indicates the required degree of confidence that an integrated
|
|
system comprising hardware and software will meet its specified safety requirements\<close>
|
|
|
|
Definition*[tester::concept]\<open>an entity that carries out testing\<close>
|
|
|
|
Definition*[testing::concept]
|
|
\<open>process of executing software under controlled conditions as to ascertain its behaviour and
|
|
performance compared to the corresponding requirements specification\<close>
|
|
|
|
Definition*[TCT1::concept, tag="''tool class T1''"]
|
|
\<open>generates no outputs which can directly or indirectly contribute to the executable code
|
|
(including data) of the software NOTE 11 examples include: a text editor or a requirement or
|
|
design support tool with no automatic code generation capabilities; configuration control tools.\<close>
|
|
|
|
Definition*[TCT2::concept,tag="''tool class T2''"]
|
|
\<open>supports the test or verification of the design or executable code, where errors in the tool
|
|
can fail to reveal defects but cannot directly create errors in the executable software
|
|
NOTE T2 examples include: a test harness generator; a test coverage measurement tool; a static
|
|
analysis tool. reproduce defined versions and be the input for future releases at enhancements or
|
|
at upgrade in the maintenance phase
|
|
\<close>
|
|
|
|
Definition*[TCT3::concept, tag="''tool class T3''"]
|
|
\<open>generates outputs which can directly or indirectly contribute to the executable code
|
|
(including data) of the safety related system NOTE T3 examples include: a source code compiler,
|
|
a data/algorithms compiler, a tool to change set-points during system operation; an optimising
|
|
compiler where the relationship between the source code program and the generated object code is
|
|
not obvious; a compiler that incorporates an executable run-time package into the executable code.
|
|
\<close>
|
|
Definition*[traceability::concept]
|
|
\<open>degree to which relationship can be established between two or more products of a development
|
|
process, especially those having a predecessor/successor or master/subordinate relationship to one
|
|
another\<close>
|
|
|
|
Definition*[validation::concept]
|
|
\<open>process of analysis followed by a judgment based on evidence to
|
|
documentation, software or application) fits the user needs,in particular with respect to safety
|
|
and quality and determine whether an item (e.g. process, with emphasis on the suitability of its
|
|
operation in accordance to its purpose in its intended environment\<close>
|
|
|
|
Definition*[validator::concept]
|
|
\<open>entity that is responsible for the validation\<close>
|
|
|
|
Definition*[verification::concept]
|
|
\<open>process of examination followed by a judgment based on evidence that output items (process,
|
|
documentation, software or application) of a specific development phase fulfils the requirements of
|
|
that phase with respect to completeness, correctness and consistency.
|
|
NOTE Verification is mostly based on document reviews (design, implementation, test documents etc.).
|
|
\<close>
|
|
|
|
Definition*[verifier::concept]
|
|
\<open>entity that is responsible for one or more verification activities\<close>
|
|
|
|
|
|
section\<open>Organization, Roles and Responsabilities\<close>
|
|
text\<open>see also section \<^emph>\<open>Software management and organization\<close>.\<close>
|
|
|
|
datatype role = PM (* Program Manager *)
|
|
| RQM (* Requirements Manager *)
|
|
| DES (* Designer *)
|
|
| IMP (* Implementer *)
|
|
| ASR (* Assessor *)
|
|
| INT (* Integrator *)
|
|
| TST (* Tester *)
|
|
| VER (* Verifier *)
|
|
| VnV (* Verification and Validation *)
|
|
| VAL (* Validator *)
|
|
|
|
|
|
|
|
datatype phase = SYSDEV_ext (* System Development Phase (external) *)
|
|
| SPl (* Software Planning *)
|
|
| SR (* Software Requirement *)
|
|
| SA (* Software Architecture *)
|
|
| SDES (* Software Design *)
|
|
| SCDES (* Software Component Design *)
|
|
| CInT (* Component Implementation and Testing *)
|
|
| SI (* Software Integration *)
|
|
| SV (* Software Validation *)
|
|
| SD (* Software Deployment *)
|
|
| SM (* Software Maintenance *)
|
|
|
|
abbreviation software_requirement :: "phase" where "software_requirement \<equiv> SR"
|
|
abbreviation software_architecture :: "phase" where "software_architecture \<equiv> SA"
|
|
abbreviation software_design :: "phase" where "software_design \<equiv> SD"
|
|
abbreviation software_component_design:: "phase" where "software_component_design \<equiv> SCDES"
|
|
abbreviation component_implementation_and_testing :: "phase"
|
|
where "component_implementation_and_testing \<equiv> CInT"
|
|
abbreviation software_integration :: "phase" where "software_integration \<equiv> SI"
|
|
abbreviation software_validation :: "phase" where "software_validation \<equiv> SV"
|
|
abbreviation software_deployment :: "phase" where "software_deployment \<equiv> SD"
|
|
abbreviation software_maintenance :: "phase" where "software_maintenance \<equiv> SM"
|
|
|
|
term "SR" (* meta-test *)
|
|
|
|
|
|
section\<open>Objectives, Conformance and Software Integrity Levels\<close>
|
|
|
|
datatype sil = SIL0 | SIL1 | SIL2 | SIL3 | SIL4
|
|
|
|
type_synonym saftety_integraytion_level = sil
|
|
|
|
|
|
doc_class objectives =
|
|
long_name :: "string option"
|
|
is_concerned :: "role set"
|
|
|
|
|
|
doc_class requirement = text_element +
|
|
long_name :: "string option"
|
|
is_concerned :: "role set"
|
|
|
|
text\<open>The following class permits to represent common situations where a set of requirements
|
|
decomposes a main requirement. The GSN notation favors this particular decomposition style.\<close>
|
|
doc_class sub_requirement =
|
|
decomposes :: requirement
|
|
relates_to :: "requirement set"
|
|
|
|
doc_class safety_requirement = requirement +
|
|
formal_definition :: "thm list"
|
|
|
|
|
|
text\<open>The category @{emph \<open>hypothesis\<close>} is used for assumptions from the
|
|
foundational mathematical or physical domain, so for example:
|
|
\<^item> the Mordell-Lang conjecture holds,
|
|
\<^item> euklidian geometry is assumed, or
|
|
\<^item> Newtonian (non-relativistic) physics is assumed,
|
|
Their acceptance is inherently outside the scope of the model
|
|
and can only established inside certification process by
|
|
authority argument.
|
|
\<close>
|
|
|
|
datatype hyp_type = physical | mathematical | computational | other
|
|
|
|
|
|
typ "CENELEC_50128.requirement"
|
|
|
|
doc_class hypothesis = requirement +
|
|
hyp_type :: hyp_type <= physical (* default *)
|
|
|
|
text\<open> The following sub-class of security related hypothesis might comprise, for example:
|
|
\<^item> @{term "P \<noteq> NP"},
|
|
\<^item> or the computational hardness of certain functions
|
|
relevant for cryptography (like prime-factorization).
|
|
(* speculation bu, not 50128 *)\<close>
|
|
|
|
doc_class security_hyp = hypothesis +
|
|
hyp_type :: hyp_type <= physical (* default *)
|
|
|
|
|
|
doc_class FnI = requirement +
|
|
is_concerned :: "role set" <= "UNIV"
|
|
type_synonym functions_and_interfaces = FnI
|
|
|
|
doc_class AC = requirement +
|
|
is_concerned :: "role set" <= "UNIV"
|
|
type_synonym application_conditions = AC
|
|
|
|
text\<open>The category \<^emph>\<open>assumption\<close> is used for domain-specific assumptions. It has formal, semi-formal
|
|
and informal sub-categories. They have to be tracked and discharged by appropriate
|
|
validation procedures within a certification process, by it by test or proof. \<close>
|
|
|
|
datatype ass_kind = informal | semiformal | formal
|
|
|
|
doc_class assumption = requirement +
|
|
assumption_kind :: ass_kind <= informal
|
|
|
|
text\<open> The category \<^emph>\<open>exported constraint\<close> (or \<^emph>\<open>EC\<close> for short) is used for formal application
|
|
conditions; They represent in particular \<^emph>\<open>derived constraints\<close>, i.e. constraints that arrive
|
|
as side-conditions during refinement proofs or implementation decisions and must be tracked.\<close>
|
|
|
|
doc_class EC = AC +
|
|
assumption_kind :: ass_kind <= (*default *) formal
|
|
type_synonym exported_constraint = EC
|
|
|
|
text\<open> The category \<^emph>\<open>safety related application condition\<close> (or \<^emph>\<open>SRAC\<close> for short) is used
|
|
for exported constraints assuring in judgements safety requirements of the system. \<close>
|
|
|
|
doc_class SRAC = EC +
|
|
assumption_kind :: ass_kind <= (*default *) formal
|
|
formal_repr :: "thm list"
|
|
type_synonym safety_related_application_condition = SRAC
|
|
|
|
|
|
doc_class CoAS = requirement +
|
|
is_concerned :: "role set" <= "UNIV"
|
|
type_synonym configuration_or_architecture_of_system = CoAS
|
|
|
|
doc_class HtbC = requirement +
|
|
is_concerned :: "role set" <= "UNIV"
|
|
type_synonym hazard_to_be_controlled = HtbC
|
|
|
|
doc_class SIR = requirement +
|
|
is_concerned :: "role set" <= "UNIV"
|
|
type_synonym safety_integrity_requirement = SIR
|
|
|
|
text\<open>The following class is a bit unclear about usage and seems to be in
|
|
conceptual mismatch with @{typ objectives}: \<close>
|
|
doc_class SILA = requirement +
|
|
is_concerned :: "role set" <= "UNIV"
|
|
alloc :: "sil" <= "SIL0"
|
|
type_synonym allocation_of_SIL = SILA
|
|
|
|
doc_class TC = requirement +
|
|
is_concerned :: "role set" <= "UNIV"
|
|
type_synonym timing_constraint = TC
|
|
|
|
section\<open>Software Assurance related Entities and Concepts\<close>
|
|
|
|
|
|
text{* subcategories are : *}
|
|
|
|
text\<open>Table A.13: \<close>
|
|
|
|
datatype dyn_ana_kind =
|
|
boundary_analysis (* -- Test Case Execution from Boundary Analysis *)
|
|
| error_guessing (* -- Test Case Execution from Error Guessing *)
|
|
| error_seeding (* -- Test Case Execution from Error Seeding *)
|
|
| performance_modeling (* -- Performance Modeling *)
|
|
| equivalence_class_test(* -- Equivalence Classes and Input Partition Testing*)
|
|
| structure_based_test (* -- Structure-Based Testing *)
|
|
|
|
text\<open>Table A.14: \<close>
|
|
|
|
datatype fun_test_kind =
|
|
cause_consequence_diagram (* -- Test Case Execution from Cause Consequence Diagrams *)
|
|
| prototyping (* -- Prototyping / Animation *)
|
|
| bounadry_value_analysis (* -- Boundary Value Analysis *)
|
|
| equivalence_class_test (* -- Equivalence Classes and Input Partition Testing*)
|
|
| process_simulation (* -- Process Simulation *)
|
|
|
|
|
|
text\<open>Table A.5: Verification and Testing\<close>
|
|
|
|
datatype test_coverage_criterion =
|
|
allpathk nat nat (* depth, test_coverage_degree *)
|
|
| mcdc nat (* depth, test_coverage_degree *)
|
|
| exhaustive
|
|
| dnf_E_d string nat (* equivalence class testing *)
|
|
| other string
|
|
|
|
datatype vnt_technique =
|
|
formal_proof "thm list"
|
|
| stat_analysis
|
|
| dyn_analysis dyn_ana_kind
|
|
| metrics
|
|
| traceability
|
|
| sw_error_effect_analysis
|
|
| test_coverage_for_code test_coverage_criterion
|
|
| functional_testing fun_test_kind test_coverage_criterion
|
|
| perf_testing test_coverage_criterion
|
|
| interface_testing test_coverage_criterion
|
|
| model_based_testing test_coverage_criterion (* 'modeling' unclear *)
|
|
|
|
|
|
type_synonym verification_and_testing_technique = vnt_technique
|
|
|
|
|
|
text\<open>The objective of software verification is to examine and arrive at a \<^emph>\<open>judgement\<close> based on
|
|
\<^emph>\<open>evidence\<close> that output items (process, documentation, software or application) of a specific
|
|
development phase fulfil the requirements and plans with respect to completeness, correctness
|
|
and consistency. \<close>
|
|
datatype status = complete | in_complete | reject | unclear | unknown
|
|
|
|
doc_class judgement =
|
|
refers_to :: requirement
|
|
evidence :: "vnt_technique list"
|
|
status :: status
|
|
is_concerned :: "role set" <= "{VER,ASR,VAL}"
|
|
|
|
section\<open> Design and Test Documents \<close>
|
|
|
|
doc_class cenelec_text = text_element +
|
|
phase :: "phase"
|
|
is_concerned :: "role set" <= "UNIV"
|
|
|
|
|
|
|
|
doc_class SYSREQS = cenelec_text +
|
|
phase :: "phase" <= "SYSDEV_ext"
|
|
accepts "\<lbrace>objectives||requirement||cenelec_text\<rbrace>\<^sup>+ "
|
|
type_synonym system_requirements_specification = SYSREQS
|
|
|
|
doc_class SYSSREQS = cenelec_text +
|
|
phase :: "phase" <= "SYSDEV_ext"
|
|
type_synonym system_safety_requirements_specification = SYSSREQS
|
|
|
|
doc_class SYSAD = cenelec_text +
|
|
phase :: "phase" <= "SYSDEV_ext"
|
|
type_synonym system_architecture_description = SYSAD
|
|
|
|
doc_class SYSS_pl = cenelec_text +
|
|
phase :: "phase" <= "SPl"
|
|
type_synonym system_safety_plan = SYSS_pl
|
|
|
|
doc_class SYS_VnV_pl = cenelec_text +
|
|
phase :: "phase" <= "SPl"
|
|
type_synonym system_VnV_plan = SYS_VnV_pl
|
|
|
|
doc_class SWRS = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_requirements_specification = SWRS
|
|
|
|
doc_class SWRVR = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_requirements_verification_report = SWRVR
|
|
|
|
|
|
doc_class SWTS = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_test_specification = SWTS
|
|
|
|
doc_class SWAS = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_architecture_specification = SWAS
|
|
|
|
doc_class SWDS = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_design_specification = SWDS
|
|
|
|
doc_class SWIS = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_interface_specification = SWIS
|
|
|
|
doc_class SWITS = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_integration_test_specification = SWITS
|
|
|
|
doc_class SWHITS = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_hardware_integration_test_specification = SWHITS
|
|
|
|
doc_class SWADVR = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_architecture_and_design_verification_report = SWADVR
|
|
|
|
doc_class SWCDS = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_component_design_specification = SWCDS
|
|
|
|
doc_class SWCTS = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_component_test_specification = SWCTS
|
|
|
|
doc_class SWCDVR = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_component_design_verification_report = SWCDVR
|
|
|
|
|
|
doc_class SWSCD = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_source_code_and_documentation = SWSCD
|
|
|
|
doc_class SWCTR = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_component_test_report = SWCTR
|
|
|
|
doc_class SWSCVR = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_source_code_verification_report = SWSCVR
|
|
|
|
doc_class SWHAITR = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_hardware_integration_test_report = SWHAITR
|
|
|
|
doc_class SWIVR = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_integration_verification_report = SWIVR
|
|
|
|
doc_class SWTR_global = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym overall_software_test_report = SWTR_global
|
|
|
|
doc_class SWVALR = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_validation_report = SWVALR
|
|
|
|
doc_class SWDD = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_deployment_documents = SWDD
|
|
|
|
doc_class SWMD = cenelec_text +
|
|
phase :: "phase" <= "SD"
|
|
type_synonym software_maintenance_documents = SWMD
|
|
|
|
|
|
section\<open> Software Assurance \<close>
|
|
|
|
subsection\<open> Software Testing \<close>
|
|
text\<open>Objective:
|
|
The objective of software testing, as performed by the Tester and/or Integrator,
|
|
is to ascertain the behaviour or performance of software against the corresponding test
|
|
specification to the extent achievable by the selected test coverage.
|
|
\<close>
|
|
|
|
text\<open>Outputs:
|
|
\<^enum> @{typ overall_software_test_report}
|
|
\<^enum> @{typ software_test_specification} Overall Software Test Specification
|
|
\<^enum> Overall Software Test Report
|
|
\<^enum> Software Integration Test Specification
|
|
\<^enum> Software Integration Test Report
|
|
\<^enum> Software/Hardware Integration Test Specification
|
|
\<^enum> Software/Hardware Integration Test Report
|
|
\<^enum> Software Component Test Specification
|
|
\<^enum> Software Component Test Report
|
|
\<close>
|
|
|
|
subsection\<open> Software Verification \<close>
|
|
text\<open>Objective:
|
|
The objective of software verification is to examine and arrive at a judgement based on evidence
|
|
that output items (process, documentation, software or application) of a specific development
|
|
phase fulfil the requirements and plans with respect to completeness, correctness and consistency.
|
|
These activities are managed by the @{concept \<open>verifier\<close>}.
|
|
\<close>
|
|
|
|
text\<open>Outputs:
|
|
\<^enum> Software Verification Plan
|
|
\<^enum> Software Verification Report(s)
|
|
\<^enum> Software Quality Assurance Verification Report
|
|
\<close>
|
|
|
|
subsection\<open> Software Validation \<close>
|
|
text\<open>Objective:
|
|
\<^enum>The objective of software validation is to demonstrate that the processes and their outputs are
|
|
such that the software is of the defined software safety integrity level, fulfils the software
|
|
requirements and is fit for its intended application. This activity is performed by the Validator.
|
|
\<^enum>The main validation activities are to demonstrate by analysis and/or testing that all the software
|
|
requirements are specified, implemented, tested and fulfilled as required by the applicable SIL,
|
|
and to evaluate the safety criticality of all anomalies and non-conformities based on the results
|
|
of reviews, analyses and tests.
|
|
\<close>
|
|
text\<open>Output documents:
|
|
\<^enum> Software Validation Plan
|
|
\<^enum> Software Validation Report
|
|
\<^enum> Software Validation Verification Report
|
|
\<close>
|
|
|
|
subsection\<open> Software Assessment \<close> (* other word for : formal evaluation. *)
|
|
text\<open>Objective:
|
|
\<^enum>To evaluate that the lifecycle processes and their outputs are such that the software is of the
|
|
defined software safety integrity levels 1-4 andis fit for its intended application.
|
|
\<^enum> For SIL 0 software, requirements of this standard shall be fulfilled but where a certificate stating
|
|
compliance with EN ISO 9001 is available, no assessment will be required.
|
|
\<close>
|
|
|
|
subsection\<open> Software Quality Assurance \<close>
|
|
text\<open>Objectives: To identify, monitor and control all those activities, both technical and
|
|
managerial, which are necessary to ensure that the software achieves the quality required.
|
|
This is necessary to provide the required qualitative defence against systematic faults and
|
|
to ensure that an audit trail can be established to allow
|
|
verification and validation activities to be undertaken effectively.\<close>
|
|
(* So : pretty much META *)
|
|
|
|
|
|
|
|
|
|
|
|
(* DEATH ZONE FROM HERE ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *)
|
|
|
|
|
|
section\<open> Design related Categories \<close>
|
|
|
|
doc_class design_item =
|
|
description :: string
|
|
|
|
datatype design_kind = unit | module | protocol
|
|
|
|
doc_class interface = design_item +
|
|
kind :: design_kind
|
|
|
|
|
|
section\<open> Requirements-Analysis related Categories \<close>
|
|
|
|
doc_class test_item =
|
|
nn :: "string option"
|
|
|
|
doc_class test_specification = test_item +
|
|
short_goal :: string
|
|
|
|
doc_class test_case = test_item +
|
|
descr :: string
|
|
|
|
doc_class test_result = test_item +
|
|
verdict :: bool
|
|
remarks :: string
|
|
covvrit :: test_coverage_criterion
|
|
|
|
datatype test_environment_kind = hardware_in_the_loop ("hil")
|
|
| simulated_hardware_in_the_loop ("shil")
|
|
|
|
doc_class test_environment = test_item +
|
|
descr :: string
|
|
kind :: test_environment_kind <= shil
|
|
|
|
doc_class test_tool = test_item +
|
|
descr :: string
|
|
|
|
doc_class test_requirement = test_item +
|
|
descr :: string
|
|
|
|
doc_class test_adm_role = test_item +
|
|
name :: string
|
|
|
|
doc_class test_documentation =
|
|
no :: "nat"
|
|
accepts "test_specification ~~ \<lbrace>test_case~~test_result\<rbrace>\<^sup>+ ~~ \<lbrace>test_environment||test_tool\<rbrace>\<^sup>+ ~~
|
|
\<lbrakk>test_requirement\<rbrakk> ~~ test_adm_role"
|
|
accepts " test_specification ~~ \<lbrace>test_case~~test_result\<rbrace>\<^sup>+ ~~ \<lbrace>test_environment||test_tool\<rbrace>\<^sup>+ ~~
|
|
\<lbrakk>test_requirement \<rbrakk> ~~ test_adm_role"
|
|
|
|
|
|
|
|
section\<open> META : Testing and Validation \<close>
|
|
|
|
text\<open>Test : @{concept \<open>COTS\<close>}\<close>
|
|
|
|
ML\<open>
|
|
DOF_core.name2doc_class_name @{theory} "requirement";
|
|
DOF_core.name2doc_class_name @{theory} "SRAC";
|
|
DOF_core.is_defined_cid_global "SRAC" @{theory};
|
|
DOF_core.is_defined_cid_global "EC" @{theory};
|
|
\<close>
|
|
|
|
ML\<open>
|
|
DOF_core.is_subclass @{context} "CENELEC_50128.EC" "CENELEC_50128.EC";
|
|
DOF_core.is_subclass @{context} "CENELEC_50128.SRAC" "CENELEC_50128.EC";
|
|
DOF_core.is_subclass @{context} "CENELEC_50128.EC" "CENELEC_50128.SRAC";
|
|
DOF_core.is_subclass @{context} "CENELEC_50128.EC" "CENELEC_50128.test_requirement";
|
|
\<close>
|
|
|
|
ML\<open>val {docobj_tab={maxano, tab=ref_tab},docclass_tab=class_tab,...} = DOF_core.get_data @{context};
|
|
Symtab.dest ref_tab;
|
|
Symtab.dest class_tab;
|
|
\<close>
|
|
|
|
ML\<open>
|
|
val internal_data_of_SRAC_definition = DOF_core.get_attributes_local "SRAC" @{context}
|
|
\<close>
|
|
|
|
ML\<open>
|
|
DOF_core.name2doc_class_name @{theory} "requirement";
|
|
Syntax.parse_typ @{context} "requirement";
|
|
val Type(t,_) = Syntax.parse_typ @{context} "requirement" handle ERROR _ => dummyT;
|
|
Syntax.read_typ @{context} "hypothesis" handle _ => dummyT;
|
|
Proof_Context.init_global;
|
|
\<close>
|
|
|
|
end
|
|
|