In the context of the ReSIST Project, an ontology of dependable and secure computing was created based on the article by A. Avizienis, J.-C. Laprie, B. Randell and C. Landwehr, titled "Basic concepts and taxonomy of dependable and secure computing" (see also these classification diagrams related to this article). To ease the undertanding of this ontology, this file presents it using a concise textual format (the FL notation), organized it via sections and indented lists following specialization relations, and includes the graphics from the article. The RDF+OWL/XML version of this ontology was taken as source. I supertyped some ReSIST categories with WordNet categories to allow a better retrieval of the ReSIST categories and their integration into the general knowledge base of WebKB-2. This is why some categories are prefixed ("wn#" for WordNet categories and "pm#" for categories I created) and why the authors of the relations that were not in ReSIST are explicitely represented (see the string "(pm)" after the destination of such relations). I also made some corrections whenever the representations were ontologically incorrect (most often, this happened when the use of the subtype relation was incorrect, i.e., when its meaning was not respected). Comments are used to explain the changes (see the strings "//..." or "/* ... */" within the code).
This file (or, more precisely, the representations within this file) has already been loaded in the knowledge base of WebKB-2. Hence, these representations can be queried, navigated and complemented by anyone using WebKB-2 (e.g., click on the categories pm#dependancy_or_information_security_related_process and pm#dependancy_or_information_security_attribute or, click on them below). This file is thus an input file for WebKB-2 but can also be seen as presenting another view (albeit a static one) on the ReSIST ontology.
1. Abbreviations, Ontology and Domain 2. Attributes 2.1. Dependability 2.2. Security 3. Particular Roles of some States or Processes 3.1. Threats To Dependable And Secure Systems 3.1.1. Errors 3.1.2. Failures 3.1.2.1. Consequences, Detectability and Consistency of Failures 3.1.2.2. Phases of Failure 3.1.2.3. Domains of Failure 3.1.3. Faults 3.1.3.1. Faults Categorized According To Intent Or Objective 3.1.3.2. Faults Categorized According To Other Characteristics 4. Processes 4.1. Means To Attain Dependable And Secure Systems: Fault Acceptance/Avoidance 4.1.1. Fault Acceptance: Fault Tolerance/Forecasting 4.1.1.1. Fault-Tolerance 4.4.1.1.1. Error Detection, Confinement and Recovery 4.4.1.1.2. Fault Tolerance Coverage 4.1.1.2. Fault Forecasting 4.1.2. Fault Avoidance: Fault Prevention/Removal 4.2. Dependability And Security Provision: Fault Prevention/Tolerance 4.3. Dependability And Security Analysis: Fault Removal/Forecasting 4.4. Processes of the System Life Cycle 5. Entities (Environment, System, ...)
user resist; //"resist" is the default author of the relations below
isUnprefixedIdentsAllowed:= true;
default creator: resist pm wn; //"resist#" is the default prefix
//pm is the author of the unprefixed relation names below
//WordNet categories are prefixed by "#" instead of "wn#"
ReSIST_ontology (^ The ReSIST Ontology encompasses concepts within the fields of research in
Resilient, Survivable and Dependable Systems ^)
supertype: pm#ontology,
part: Dependability-And-Security Entity;
Dependability-And-Security (^ Two somewhat overlapping concepts, with dependability being an integrating concept
that encompasses 'availability, reliability, safety, integrity and maintainability',
while security encompasses 'availability, integrity and confidentiality'. ^)
type: aktp#Research-Area (pm),
//ReSIST used the relation "supertype" instead of "type"; this was incorrect:
// Dependability-And-Security is a domain and hence, like all domains declared by AKTP,
// an individual (instance of aktp#Research-Area), not a type (a domain is a collection
// of objects, not a class of objects, it does not have instances)
domain_object: //ReSIST used the relation "subtype" here; this was incorrect since an attribute or a
// process is not a "subtype" of a domain but may be an "object" (of study) in this domain.
//Using the relation "domain_object" is a local change to the structure of the ontology but
// there is no alternative here. The same kind of change had to be made in Section 5 too.
//The other changes made to this ontology are minor with respect to the
// structure of its subtype hierarchy.
pm#dependancy_or_information_security_attribute (pm) pm#dependancy_or_information_security_related_process (pm);
//Note: I (pm) added these last two intermediary types in order to organize the
// ontology and thus ease its understanding and possible future extensions
pm#dependancy_or_information_security_attribute //supertype: pm#security_attribute, //stated elsewhere subtype: Dependability Security (pm); |
 |
Dependability___High-Confidence___Survivability (^ Ability to deliver service that can justifiably
be trusted. A more usable definition is: ability to avoid service failures that
are more frequent and more severe than is acceptable. ^)
subtype: Dependence Trust Attribute-Of-Dependable-Systems,
supertype: #dependability (pm);
Dependence (^ The dependence of system A on system B represents the extent to which
system A's dependability is (or would be) affected by that of System B. ^);
Trust (^ Accepted dependence (willing or not, careful or not), i.e., acceptation by the
user of changes (willing or not, careful or not) in her dependability on a given system ^);
Attribute-Of-Dependable-Systems
(^ The dependability properties that are expected from a system, and in terms of which a system's
dependability can be assessed with respect to the threats and the means to oppose these threats. ^)
subtype: Availability Integrity Maintainability Reliability Safety Robustness;
Availability (^ 1) Readiness for correct service; 2) Measure of the delivery of correct
service with respect to the alternation of correct and incorrect service. ^)
supertype: #accessibility,
core_domain_object of: acm#C.4.5;
//supertype: Attribute-Of-Dependable-Systems Attribute-Of-Secure-Systems;
Integrity (^ The absence of improper system alterations. ^)
supertype: #integrity,
core_domain_object of: acm#H.2.0.0 acm#H.2.7.3;
//supertype: Attribute-Of-Dependable-Systems Attribute-Of-Secure-Systems;
Maintainability (^ 1) Ability to undergo repairs and modifications;
2) Measure of the continuous delivery of incorrect service;
3) Measure of the time to restoration from the last failure occurrence. ^)
core_domain_object of: acm#C.4.5 acm#D.2.7;
Reliability (^ 1) Continuity of correct service; 2) Measure of continuous delivery of
correct service; 3) Measure of the time to failure. ^)
core_domain_object of: acm#Reliability (pm);
//and therefore of: acm#B.1.3 acm#B.2.3 acm#B.3.4 acm#B.4.5 acm#B.4.5.3
// acm#B.6.2 acm#B.7.3 acm#B.8 acm#B.8.0 acm#B.8.1 acm#C.4.5
// acm#D.2.4.6 acm#D.4.5 acm#G.3.10 acm#G.4.6
Safety (^ 1) No catastrophic failures affecting the system user(s) and its environment;
2) Measure of the continuous delivery of either correct service or
incorrect service after non-catastrophic failure;
3) Measure of the time to catastrophic failure. ^)
core_domain_object of: acm#K.4.1.3;
Robustness (^ Dependability with respect to external faults. ^)
core_domain_object of: acm#G.4.6;
Security (^ Concurrent existence of a) availability for authorized actions only,
b) confidentiality, and c) integrity (the absence of improper system state
alterations, with 'improper' having the meaning 'unauthorized'). ^)
subtype: Attribute-Of-Secure-Systems,
core_domain_object of: acm#Security (pm); //and therefore, as a subset, the list given in the mapping:
//acm#C.2.0.2 acm#D.4.6 acm#H.2.0.0 acm#H.2.7.3
//acm#K.4.4.5 acm#K.6.5 acm#K.6.5.3
//acm#K.6.m.1 (pm); //not acm#K.6.5.m.1 (unknown category; error in the mapping)
Attribute-Of-Secure-Systems (^ The security properties that are expected from a system, and in terms of
which a system's security can be assessed with respect to the threats and
the means to oppose these threats. ^)
subtype: Availability Integrity Confidentiality Accountability
Authenticity Nonrepudiability;
/* Already declared in the previous section:
Availability (^ 1) Readiness for correct service; 2) Measure of the delivery of correct service
with respect to the alternation of correct and incorrect service. ^);
//supertype: Attribute-Of-Dependable-Systems Attribute-Of-Secure-Systems;
Integrity (^ The absence of improper system alterations. ^);
//supertype: Attribute-Of-Dependable-Systems Attribute-Of-Secure-Systems;
*/
Confidentiality (^ The absence of unauthorized disclosure of information. ^)
definition: "ensuring that information is accessible only to those authorized to have access" (iso),
core_domain_object of: acm#K.4.1.5;
Accountability
(^ Availability&integrity of the identity of the person who performed an operation. ^);
Authenticity (^ The integrity of a message content and origin, and possibly of other
information, such as the time of emission ^)
core_domain_object of: acm#D.4.6.1 acm#K.6.5.0 acm#K.6.5.4;
Nonrepudiability (^ The availability and integrity of the identity of the sender of a message
(non-repudiation of origin), or of the receiver (non-repudiation of reception). ^);
Threats-To-Dependable-And-Secure-Systems is a problematic identifier
since with such a name this category should refer to a collection ("threats" is in the plural)
and hence would not have category with singular names as subtypes.
Hence, I gave it an additional (and more appropriate) identifier, by using
the same name in the singular. Another solution would have been to consider this category as a collection
and use a "member" relation instead of the "subtype" relation. However, this would have changed the
the structure of the ontology. Hence, it is better (and simpler) to assume that the authors simply
chose an inappropriate name.
Threats-To-Dependable-And-Secure-Systems
(^ The threats to the dependability and/or security of a system can be classified
as faults, errors, and failures. ^)
name: Threat-To-Dependable-And-Secure-Systems (pm),
subtype: Error Failure Fault,
supertype: #failure.happening (pm);
In ReSIST, some categories are used for representing "distinctions" that is,
partitions of exclusive subtypes of a certain type. The problem is that these categories are not
represented as particular kinds of sets (which they are) but as subtypes of this type and supertypes
of these subtypes. In other words, the meaning of the subtype relation is not respected.
This is corrected below by using an adequate construct for representing "distinctions"
(the "{...}" construct in FL) and putting the ReSIST "distinctions" categories within comments.
Error (^ The part of the total state of a system that may lead to its subsequent service failure. ^)
name: security_error (pm),
supertype: pm#error (pm),
core_domain_object of: acm#E.4.1,
subtype: {Content-Error Timing-Error}(pm) //Error-Domain
{(Consistent-Error Inconsistent-Error)}(pm) //Error-Consistency
{Minor-Error Catastrophic-Error}(pm) //Error-Consequences
{Single-Error Multiple-Related-Errors}(pm)
{Detected-Error Latent-Error}(pm);
//Note: "{" and "}" delimit a partition of exclusive subtypes, and
// "{(" and ")}" delimit a "complete" partition of exclusive subtypes;
// "(pm)" after a partition represents the fact that pm created this partition.
/* Error-Domain (^ The error domain combines the concepts of errors of content and of timing. ^)
subtype: Content-Error Timing-Error;
*/
Content-Error (^ An error such that should there be a resulting failure the content of
the information delivered at the service interface (i.e., the
service content) will deviate from implementing the system function. ^);
Timing-Error (^ error that could lead to a failure such that the time of arrival or the
duration of the information delivered at the service interface (i.e., the
timing of service delivery) deviates from implementing the system function. ^);
/* Error-Consistency (^ The extent to which a set of errors are consistent, i.e. are in agreement,
with each other. ^)
subtype: Consistent-Error Inconsistent-Error;
*/
Consistent-Error (^ An error that occures identically in given circumstances, so that any
resulting incorrect service is perceived identically by all system users. ^);
Inconsistent-Error (^ An error that occures differently in given circumstances, with the
result that any resulting incorrect service might be perceived
differently by various system users ^);
/* Error-Consequences (^ The possible effects, i.e.further errors and failures, of an error. ^)
subtype: Minor-Error Catastrophic-Error;
*/
Minor-Error (^ A minor error is one such that the harmful consequences of the
failures that it could lead to are of similar cost to the
benefits provided by correct service delivery. ^);
Catastrophic-Error (^ An error whose potential harmful consequences are orders of magnitude,
or even incommensurably, higher in cost than the benefit provided by
correct service delivery. ^);
Single-Error (^ Single errors are errors that affect one component only. ^);
Multiple-Related-Errors (^ Some faults (e.g., a burst of electromagnetic radiation) can
simultaneously cause errors in more than one component.
Such errors are called multiple related errors. ^);
Detected-Error (^ An error is detected if its presence is indicated by an
error message or error signal. ^);
Latent-Error (^ Errors that are present but not detected are latent errors. ^);
Failure (^ An event that occurs when the service that a system delivers deviates
from the correct service. ^)
name: security_failure (pm),
supertype: pm#failure (pm),
subtype: {Service-Failure Development-Failure}(pm) //Failure-Phase
{Catastrophic-Failure Minor-Failure}(pm) //Failure-Consequence
{Signalled-Failure Unsignalled-Failure False-Alarm}(pm) //Failure-Detectability
{Consistent-Failures Inconsistent-Failures}(pm) //Consistency-Of-Failure
{Non-Numerical-Content-Failure Numerical-Content-Failure} //Content-Failure
{Early-Timing-Failure Late-Timing-Failure}(pm) //Timing-Failure
{Halt-Failure Erratic-Failure}(pm); //Content-And-Timing-Failure
 |
 |
/* Failure-Consequence
(^ The severity of the effects of a failure on a system's enviroment. ^)
subtype: Catastrophic-Failure Minor-Failure;
*/
Catastrophic-Failure
(^ A failure whose harmful consequences are orders of magnitude, or even
incommensurably, higher in cost than the benefit provided by
correct service delivery. ^);
Minor-Failure
(^ A minor failure is one such that the harmful consequences are of
similar cost to the benefits provided by correct service delivery ^);
/* Failure-Detectability
(^ The indication of whether of not failures are signalled as such. ^)
subtype: Signalled-Failure Unsignalled-Failure False-Alarm;
*/
Signalled-Failure
(^ A failure such that the cessation of system service is signalled to the user. ^);
Unsignalled-Failure
(^ Undetected incorrect and invalid service. ^);
False-Alarm
(^ A reported detection of a failure when the system service is in fact correct. ^);
/* Consistency-Of-Failure
(^ Identicality, or otherwise, of the incorrect service perceived by system users. ^)
subtype: Consistent-Failures Inconsistent-Failures;
*/
Consistent-Failures___Consistent-Failure
(^ Incorrect service is perceived identically by all system users. ^);
Inconsistent-Failures___Inconsistent-Failure___Byzantine-Failure
(^ Failures such that some or all system users perceive differently
incorrect service (some users may actually perceive correct service);
inconsistent failures are often called Byzantine failures. ^);
/* Failure-Phase (^ Indication of whether the failure occurs during system service or development ^)
subtype: Service-Failure Development-Failure;
*/
Service-Failure (^ A service failure, often abbreviated to failure, is an event that
occurs when a system's delivered service deviates from correct service. ^);
Development-Failure (^ A complete development failure causes the development process to be
terminated before a system is accepted for use and placed into service. ^)
subtype: Complete-Development-Failure Partial-Development-Failure;
Complete-Development-Failure (^ A failure that causes the development process to be terminated
before a system is accepted for use and placed into service. ^)
subtype: Budget-Failure Schedule-Failure;
Budget-Failure (^ A failure that occurs when the funds or time required to complete
the development effort exceed what is acceptable. ^);
Schedule-Failure (^ Development failure such that the projected delivery schedule slips
to a point in the future where the system would be technologically
obsolete or functionally inadequate for the user's needs. ^);
Partial-Development-Failure (^ Development failure not severe enough to lead to project termination. ^)
subtype: Downgrading Overrun;
Downgrading (^ A form of partial development failure, in which a developed system
is delivered with less functionality, lower performance, or is
predicted to have lower dependability or security, than was
required in the original system specification. ^);
Overrun (^ Budget or schedule overruns occur when the development is completed but the
funds or time needed to complete the effort exceed the original estimates. ^);
/* Failure-Domain (^ The types of failure: content, early or late timing, halt or erratic ^)
subtype: Content-Failure Timing-Failure Content-And-Timing-Failure;
*/
/* Content-Failure (^ A failure such that the content of the information delivered at the
service interface (i.e., the service content) deviates from implementing
the system function. ^)
subtype: Non-Numerical-Content-Failure Numerical-Content-Failure;
*/
Non-Numerical-Content-Failure (^ A failure such that the content of the (non-numerical) information
delivered at the service interface (i.e., the service content)
deviates from implementing the system function. ^);
Numerical-Content-Failure (^ A failure such that the content of the (numerical) information
delivered at the service interface (i.e., the service content)
deviates from implementing the system function. ^);
/* Timing-Failure (^ A timing failure occurs when the time of arrival or the duration of
the information delivered at the service interface (i.e., the timing
of service delivery) deviates from implementing the system function. ^)
subtype: Early-Timing-Failure Late-Timing-Failure;
*/
Early-Timing-Failure (^ Service is delivered too early by a system. ^);
Late-Timing-Failure (^ Service is delivered too late by a system. ^);
/* Content-And-Timing-Failure (^ Content concerns the information delivered at a system's
service interface, timing concerns when this content is delivered ^)
subtype: Halt-Failure Erratic-Failure;
*/
Halt-Failure (^ A failure of a system such that the service is halted (the external
state becomes constant, i.e., system activity, if there is any, is
no longer perceptible to the users). ^)
subtype: Silent-Failure;
Silent-Failure (^ A failure such that no service at all is delivered at a system's
service interface (e.g., no messages are sent in a distributed system). ^);
Erratic-Failure (^ Failure such that, although a service is delivered (the system is
not halted), it is erratic (e.g., babbling) ^);
Fault (^ The adjudged or hypothesized cause of an error. ^)
name: security_fault (pm),
supertype: pm#fault (pm),
subtype: {(Deliberate-Fault Non-Deliberate-Fault)}(pm) //Fault-Intent
{(Malicious-Fault Non-Malicious-Fault)}(pm) //Fault-Objective
{(Development-Fault Operational-Fault)}(pm) //Fault-Phase
{(Internal-Fault External-Fault)}(pm) //System-Boundaries
{(Natural-Fault Human-Made-Fault)}(pm) //Phenomenological-Cause-Of-Fault
{(Hardware-Fault Software-Fault)}(pm) //Fault-Dimension
{(Accidental-Fault Incompetence-Fault)}(pm) //Fault-Capability
{(Permanent-Fault Transient-Fault)}(pm) //Fault-Persistence
{(Active-Fault Dormant-Fault)}(pm)
Configuration-Fault Reconfiguration-Fault
Physical-Fault;
 |
 |
/* Fault-Intent (^ The distinction between deliberate and non-deliberate faults. ^)
subtype: Deliberate-Fault Non-Deliberate-Fault;
*/
Deliberate-Fault (^ A fault created as a result of a conscious decision, with or without
a malicious intent. ^);
Non-Deliberate-Fault (^ A fault that is created as a result of an unconscious decision. ^);
/* Fault-Objective (^ The distinction between malicious and non-malicious faults. ^)
subtype: Malicious-Fault Non-Malicious-Fault;
*/
Malicious-Fault (^ A fault that is created as an act of ill-will or in a spirit of mischief. ^)
subtype: Malicious-Logic-Fault Intrusion-Attempt;
Malicious-Logic-Fault (^ Malicious logic faults encompass development faults such as
Trojan horses, logic or timing bombs, and trapdoors, as well as
operational faults such as viruses, worms, or zombies. ^)
subtype: Trojan-Horse Logic-Bomb Trapdoor Virus
Worm Zombie,
core_domain_object of: acm#D.4.6.4 acm#K.6.5.2; //"Invasive_software"
Trojan-Horse (^ A program that masquerades as a useful service but exploits rights of
the program's user - rights that are not possessed by the author of
the Trojan horse - in a way the user does not intend. ^);
Logic-Bomb___Timing-Bomb (^ A piece of code intentionally inserted into a software system that
will set off a malicious function when specified conditions are met. ^);
Trapdoor (^ A hidden piece of code that responds to a special input, allowing
its user to access to resources without passing through the normal
security enforcement mechanism. ^);
Virus (^ A trojan horse that replicates itself by copying its code into
other program files. ^);
Worm (^ A trojan horse that replicates itself by creating new processes or files
to contain its code, instead of modifying existing storage entities. ^);
Zombie (^ A computer attached to a network that has been taken over by an
outside user, e.g. in order to spread spam mail. ^);
Intrusion-Attempt (^ As operational external fault - it may be performed by system
operators or administrators who are exceeding their rights, and
may use physical means to cause faults: power fluctuation, radiation,
wire-tapping, heating/cooling, etc. ^)
core_domain_object of: acm#K.6.5.4;
Non-Malicious-Fault (^ A fault that is not created as an act of ill-will or in a spirit of mischief. ^);
/* Fault-Phase
(^ The distinction between development and operational faults. ^)
subtype: Development-Fault Operational-Fault;
*/
Development-Fault
(^ Development faults include all fault classes that occur during
development of a system (from specification to realization). ^);
Operational-Fault
(^ A fault that arises during usage of a system. ^);
/* System-Boundaries
(^ System boundaries are the common frontier between systems and their environment. ^)
subtype: Internal-Fault External-Fault;
*/
Internal-Fault
(^ A fault that lies within the system boundaries. ^);
External-Fault
(^ A fault that is outside of the system boundaries, and propagates
errors into the system via interaction or interference. ^)
subtype: Intrusion-Attempt (pm) Interaction-Fault (pm);
//pm added these two subtype relations that were not represented in ReSIST
Interaction-Fault
(^ An external fault, i.e. a fault that is outside of the system boundaries,
and propagates errors into the system via interaction or interference. ^);
/* Phenomenological-Cause-Of-Fault
(^ This term subsumes the concepts of a natural fault and a human-made fault. ^)
subtype: Natural-Fault Human-Made-Fault;
*/
Natural-Fault
(^ A fault that is due to adverse physical phenomena. ^)
subtype: Production-Defect;
Production-Defect
(^ A type of fault, classed as a natural fault, that arises during
hardware production. ^);
Human-Made-Fault
(^ A fault that is the result of human activity (or inactivity). ^)
subtype: Omission-Fault Commission-Fault;
Omission-Fault
(^ An omission fault (or simply an omission) is a human-made fault,
namely the absence of action when an action should be performed. ^);
Commission-Fault
(^ Human-made fault resulting from a wrong action. ^);
/* Fault-Dimension
(^ In particular, the distinction between hardware and software faults. ^)
subtype: Hardware-Fault Software-Fault;
*/
Hardware-Fault
(^ A fault that appears in, or affects, hardware. ^);
Software-Fault
(^ A fault that affects programs or data. ^);
/* Fault-Capability
(^ This expreses the distinction between faults that occur accidentally,
and those that are the result of incompetence. ^)
subtype: Accidental-Fault Incompetence-Fault;
*/
Accidental-Fault
(^ Fault originating or arising inadvertently. ^);
Incompetence-Fault
(^ A fault that is the result of human incompetence - a harmful
mistake or bad decision made by a person who lacks the necessary
professional competence. ^);
/* Fault-Persistence
(^ The distinction between permanent and transient faults. ^)
subtype: Permanent-Fault Transient-Fault;
*/
Permanent-Fault
(^ A fault whose presence is presumed to be continuous in time. ^);
Transient-Fault
(^ A fault whose presence is bounded in time. ^);
// Active/dormant faults
Active-Fault
(^ A fault is active when it produces an error, otherwise it is dormant.
An active fault is either a) an internal fault that was previously
dormant and that has been activated by the computation process or
environmental conditions, or b) an external fault.
Fault activation is the application of an input (the activation pattern)
to a component that causes a dormant fault to become active.
Most internal faults cycle between their dormant and active states.^);
Dormant-Fault (^A non-active fault^);
Configuration-Fault
(^ A broad class of human-made operational faults such as wrong setting of
parameters that can affect security, networking, storage, middleware, etc. ^);
Reconfiguration-Fault
(^ A fault that occurs during configuration changes performed during
adaptive or augmentative maintenance performed concurrently with system
operation (e.g., introduction of a new software version on a network server). ^);
Physical-Fault
(^ A fault that effects hardware. ^);
/* already stated somewhere else:
pm#dependancy_or_information_security_related_process_generalized_by_a_category_in_the_RESIST_ontology
subtype: Means-To-Attain-Dependable-And-Secure-Systems
Threats-To-Dependable-And-Secure-Systems
Dependability-And-Security-Provision Dependability-And-Security-Analysis
Fault-Acceptance Fault-Avoidance System-Life-Cycle; //or: process_of_the_System-Life-Cycle
//the folowing types are specialized in this other file
information_assurance information security computer_security
process_supporting_a_particular_security_attribute cryptographic_process
process_supporting_the_security_of_a_particular_object, //specialized for RFID objects in this other file
supertype: pm#process_playing_some_role (pm);
*/
Means-To-Attain-Dependable-And-Secure-Systems
(^ Fault prevention/tolerance support the delivering a trustable service.
Fault removal/forecasting justify why the functional and the dependability & security
specifications are adequate and that the system is likely to meet them. ^)
subtype: Fault-Acceptance (pm) Fault-Avoidance (pm);
Fault-Acceptance (^ The association of fault tolerance and fault forecasting, i.e., how to live
with systems that are subject to faults. ^)
subtype: Fault-Tolerance Fault-Forecasting;
Fault-Tolerance___Resilience___Self-Repair___Self-Healing
(^ Means of avoiding service failures despite the presence of faults. ^)
//supertype: Means-To-Attain-Dependable-And-Secure-Systems
// Dependability-And-Security-Provision Fault-Acceptance,
subtype: Fault-Masking Design-Diversity Reflection
Error-Detection Error-Confinement-Area Recovery Coverage,
core_domain_object of: acm#Reliability (pm)
acm#D.2.0.0 acm#D.4.6 acm#D.4.6.0 acm#D.4.6.3 acm#D.4.6.5
acm#E.3.0 acm#E.3.2 acm#E.3.3;
//no acm#E.3.4 (unknown category; error in the mapping?)
//acm#Reliability implies among other domains: acm#B.1.3 acm#B.2.3
// acm#B.3.4 acm#B.4.5 acm#B.8.1 acm#C.4.1 acm#D.4.5.2 //"fault"
Fault-Masking (^ Fault masking, or simply masking, results from the systematic usage of
compensation. Such masking will conceal a possibly progressive and
eventually fatal loss of protective redundancy. ^)
core_domain_object of: acm#B.1.3.2 acm#B.2.3.2;
Design-Diversity (^ An approach to the production of systems, involving the provision of the
same function from separate designs and implementations. ^)
core_domain_object of: acm#ACM_Redundant_design;
//and therefore of: acm#B.1.3.2 acm#B.2.3.2 acm#B.3.4.2 acm#B.4.5.4 acm#B.5.3.2
// acm#B.6.2.2 acm#B.7.3.2;
Reflection (^ Ability of a computer program to 'observe' and possibly to modify its
own structure and behavior. ^);
Error-Detection___Error-Checking
(^ The action of identifying the presence of an erroneous system state. ^)
subtype: Concurrent-Detection Preemptive-Detection Self-Checking-Component,
core_domain_object of: acm#ACM_Error-checking (pm);
//and therefore of: acm#B.1.3.1 acm#B.2.3.1 acm#B.3.4.1 acm#B.4.5.2 acm#B.5.3.1
// acm#B.6.2.1 acm#B.7.3.1;
Concurrent-Detection (^ Error detection that takes place during normal service delivery. ^);
Preemptive-Detection (^ Error detection that takes place while normal service delivery is
suspended, checking a system for latent errors and dormant faults. ^);
Self-Checking-Component (^ A component which has the required functional processing capability
together with concurrent error detection mechanisms. ^)
core_domain_object of: acm#ACM_Built-in_tests;
//and therefore of: acm#B.4.5.0 acm#B.5.3.0 acm#B.6.2.0 acm#B.7.3.0;
Error-Confinement-Area (^ That part of a system's potential activites beyond which errors are prevented
from propagating, for example via the provision of self-checking mechanisms. ^);
Recovery (^ Error and/or fault handling ^)
subtype: Error-Handling Fault-Handling,
core_domain_object of: acm#ACM_Recovery (pm);
//and therefore of: acm#D.2.5.5 acm#E.5.0 acm#H.2.7.2
// acm#H.2.2.2 //not acm#H.2.2.
Error-Handling___Error-Control___Error-Correction
(^ 1) Transformation of an erroneous state into an error-free state;
2) Rollback, compensation, or rollforward. ^)
subtype: Compensation Rollback RollForward,
core_domain_object of: acm#D.2.5.5;
Compensation (^ A form of error handling that can be provided in the case that
the erroneous state contains enough redundancy to enable its
transformation into an error-free state. ^)
core_domain_object of: acm#ACM_Redundant_design (pm);
//and therefore of: acm#B.1.3.2 acm#B.2.3.2 acm#B.3.4.2 acm#B.4.5.4
// acm#B.6.2.2 acm#B.7.3.2; //and B.5.3.2
Rollback (^ A form of error handling in which the state transformation consists of
bringing a system back to a saved state that existed prior to error occurrence. ^)
core_domain_object of: acm#D.4.5.0 acm#D.4.5.1;
RollForward (^ A form of error handling in which the restart state is a new state. ^);
Fault-Handling (^ 1) Prevention of faults from being activated again, and
2) Fault diagnosis, fault isolation, system reconfiguration,
system reinitialization. ^)
subtype: Diagnosis Isolation Reconfiguration Reinitialisation;
Diagnosis (^ The identification of the cause, i.e. the fault(s) that led to the
existence of one or more errors, and potentially to system failure. ^)
core_domain_object of: acm#ACM_diagnostics (pm);
//and therefore of: B.1.3.0 acm#B.2.3.0 acm#B.3.4.0 acm#B.4.5.1 acm#D.2.5.2;
Isolation (^ Physical or logical exclusion of faulty components from further
particpation in service delivery, i.e. making the fault a dormant one. ^)
core_domain_object of: acm#D.4.6.0 acm#D.4.6.3 acm#D.4.6.5;
Reconfiguration (^ The action of either switching in spare components or re-assigning
tasks among non-failed components. ^);
Reinitialisation (^ Fault handling that involves resetting a system to its initial state. ^);
Coverage___Fault-Tolerance_Coverage (^ A measure of the representativeness of the situations to which a system
is subjected during its analysis compared to the actual situations that
the system will be confronted with during its operational life. ^)
subtype: Error-And-Fault-Handling-Coverage Failure-Mode-Coverage
Assumption-Coverage;
Error-And-Fault-Handling-Coverage (^ A measure of the representativeness of the situations to which a
system's provisions for error and fault handling are subjected during
their analysis compared to the actual situations that they will be
confronted with during the system's operational life. ^);
Failure-Mode-Coverage (^ A measure of the representativeness of the failure mode situations to
which a system is subjected during its analysis compared to the
actual situations that the system will be confronted with during
its operational life. ^);
Assumption-Coverage (^ A measure of the representativeness of the assumptions which are
during the analysis of a system compared to the actual situations
that the system will be confronted with during its operational life. ^);
Fault-Forecasting (^ The means of estimating the present number, the future incidence,
and the likely consequences of faults. ^)
//supertype: Means-To-Attain-Dependable-And-Secure-Systems
// Dependability-And-Security-Analysis Fault-Acceptance,
subtype: Ordinal-Evaluation Probabilistic-Evaluation
Performability Dependability-And-Security-Benchmarks,
core_domain_object of: acm#ACM_Worst-case_analysis (pm);
Ordinal-Evaluation___Qualitative-Evaluation
(^ Qualitative, or ordinal, evaluation, aims to identify, classify, and rank
a system's failure modes, or the event combinations (component failures
or environmental conditions) that would lead to system failures. ^);
Probabilistic-Evaluation___Quantitative-Evaluation
(^ Quantitative, or probabilistic, evaluation, aims to evaluate in
terms of probabilities the extent to which specified dependability
and or security attributes are satisfied ^)
subtype: Evaluation-Testing Modelling,
core_domain_object of: acm#G.3.4 acm#G.3.10 acm#G.3.11;
Evaluation-Testing___Operational-Testing
(^ Testing for the purpose of evaluating a system's behaviour with
respect to fault occurrences or activations. ^);
Modelling (^ A statistical means of evaluating the dependability and security of
a complex dynamic system. ^);
Performability (^ A performance-related measure of dependability, particularly used for
evaluating degradable systems. ^);
Dependability-And-Security-Benchmarks (^ Set of tests to assess a system behavior in the presence
of faults, and hence a) characterize the dependability and security of a system,
and b) compare alternative/competitive solutions. ^);
Fault-Avoidance (^ The association of fault prevention and fault removal. ^)
subtype: Fault-Prevention Fault-Removal
http://en.wikipedia.org/wiki/Computer_security_incident_management (pm);
Fault-Prevention (^ Means of preventing the occurrence or introduction of faults. ^)
core_domain_object of: acm#D.2 acm#D.2.9.7 acm#H.2.2.1 acm#K.6.4.2;
//supertype: Means-To-Attain-Dependable-And-Secure-Systems
// Dependability-And-Security-Provision Fault-Avoidance;
Fault-Removal (^ Means of reducing the number and severity of faults. ^)
//supertype: Means-To-Attain-Dependable-And-Secure-Systems
// Dependability-And-Security-Analysis Fault-Avoidance,
subtype: Validation Verification,
core_domain_object of: acm#D.2.7 acm#D.2.7.0 acm#F.3.1 acm#H.2.2.1
acm#F.4.1.4; //http://resist.ecs.soton.ac.uk/ontology/mapping/mapping.txt
// states different domains according to the different supertypes
// why (since the meaning is the same) ?
Validation (^ Checking of a system specification ensuring that the 'right product'
has been built (while 'verification' ensures that the product was
'built right'). ^)
core_domain_object of: acm#D.2.4.8;
Verification
(^ Checking of a system specification ensuring that product is 'built right'
(while 'validation' ensures that the product was the 'right product'). ^)
subtype: Dynamic-Verification Static-Verification
Verification-Condition Nonregression-Verification,
core_domain_object of: acm#B.2.2 acm#B.2.3 acm#B.3.4 acm#B.4.4 acm#B.4.5 acm#B.6.3
acm#B.7.2.0 acm#D.2.4.3 acm#D.4.8 acm#F.3.1 acm#F.3.1.3
acm#Verification; //and therefore (among others);
//and therefore: acm#ACM_Verification implies acm#B.1.4.4 acm#B.2.2.1 acm#B.4.4.2
// acm#B.5.2.4 acm#B.6.3.5 acm#B.7.2.4 acm#C.2.2.2 acm#D.2.4 acm#D.4.5.3
// acm#D.4.6.6 acm#G.4.8 acm#I.2.2.4
// but also F.3.1.3 (forgotten in the mapping?)
Dynamic-Verification (^ Verifying a system through exercising it; the inputs supplied to the
system can be either symbolic in the case of symbolic execution, or
actual in the case of verification testing, usually simply termed testing. ^)
subtype: Symbolic-Execution Testing;
Symbolic-Execution (^ Verifying a system through exercising it constitutes
dynamic verification; the inputs supplied to the system can be
either symbolic in the case of symbolic execution, or actual
in the case of verification testing, usually simply termed testing. ^)
core_domain_object of: acm#D.2.5.7;
Testing (^ Verifying a system through exercising it constitutes
dynamic verification; the inputs supplied to the system can be
either symbolic in the case of symbolic execution, or actual
in the case of verification testing, usually simply termed testing. ^)
subtype: Deterministic-Testing Random-Testing Oracle-Problem
Golden-Unit Back-To-Back-Testing,
core_domain_object of: acm#ACM_testing; /* and therefore (among others):
acm#B.1.3 acm#B.1.3.1 acm#B.2.3 acm#B.2.3.3 acm#B.3.4
acm#B.4.5 acm#B.4.5.5 acm#B.5.3 acm#B.5.3.3 acm#B.5.3.4
acm#B.6.2 acm#B.6.2.3 acm#B.6.3.5
acm#B.7.3 acm#B.7.3.3 acm#B.7.3.4 acm#B.8.1
acm#D.2.5 acm#D.2.5.0 acm#D.2.5.1 acm#D.2.5.3 acm#D.2.5.4
acm#D.2.5.6 acm#D.2.5.8 acm#D.2.5.9 acm#D.3.4.2 acm#G.4.1; */
Deterministic-Testing (^ A form of testing in which the test patterns are predetermined by
a selective choice. ^);
Random-Testing___Statistical-Testing (^ A form of testing in which the test patterns are selected
according to a defined probability distribution on the input domain;
the distribution and the number of input data are determined
according to the given fault model or criteria. ^)
core_domain_object of: acm#D.2.4.7;
Oracle-Problem (^ In statistical testing of a system, observing the test outputs and
deciding whether or not they satisfy the verification conditions is
known as the oracle problem. ^);
Golden-Unit (^ A reference system againt which the results from a system under
test are compared, so as to test for physical faults. ^);
Back-To-Back-Testing (^ A means of testing for physical faults involving comparing the results
from a system under test for a given input sequence against those
from a prototype, or another implementation of the same specification. ^);
Static-Verification (^ A process of checking some required characterisitcs of a software system,
e.g. via model checking, static analysis or formal verification. ^)
subtype: Model-Checking Static-Analysis Theorem-Proving,
core_domain_object of: acm#F.3.1.3;
Model-Checking (^ Model checking is a method of algorithmically verifying that a
model (derived from a design) satisfies a given aspect of this
design's formal specification. ^)
core_domain_object of: acm#D.2.4.4;
Static-Analysis (^ A method of automated analysis of computer software that is performed
without actually executing programs built from that software, but
instead on a version of the source code or the object code. ^)
core_domain_object of: acm#D.2.4.0;
Theorem-Proving (^ The proving of mathematical theorems by a computer program, in
particular as part of a system verification task. ^)
core_domain_object of: acm#D.2.4.2 acm#F.3.1.3 acm#F.4.1.4;
Verification-Condition (^ Assertions that are generated as part of the task of system verification
and which, if proved by a theorem prover, will verify that the component
is correct. ^)
core_domain_object of: acm#D.2.4.1;
Nonregression-Verification (^ After a fault has been removed, the verification process should
normally be repeated in order to check that fault removal had no
undesired consequences; such verification is usually termed non
regression verification. ^);
Dependability-And-Security-Provision
(^ The twin provision of dependability (availability, reliability, safety, integrity
and maintainability) and security (comfidentiality, integrity and availability). ^)
subtype: Fault-Prevention Fault-Tolerance;
/* developed above in Section "Fault Avoidance (Fault Prevention/Removal)":
Fault-Prevention (^ Means of preventing the occurrence or introduction of faults. ^);
//supertype: Means-To-Attain-Dependable-And-Secure-Systems
Dependability-And-Security-Provision Fault-Avoidance;
*/
/* developed above in Section "Fault Forecasting":
Fault-Tolerance___Resilience___Self-Repair___Self-Healing
(^ Means of avoiding service failures despite the presence of faults. ^)
//supertype: Means-To-Attain-Dependable-And-Secure-Systems
// Dependability-And-Security-Provision Fault-Acceptance,
subtype: Error-Detection Recovery Fault-Masking
Error-Confinement-Area Design-Diversity Reflection Coverage;
*/
Dependability-And-Security-Analysis (^ Dependability & security analysis covers both
fault removal and fault forecasting, and is aimed at reaching confidence in the
ability of a system to deliver a service that can be trusted. ^)
subtype: Fault-Removal Fault-Forecasting;
/* developed above in Section "Fault Avoidance (Fault Prevention/Removal)":
Fault-Removal (^ Means of reducing the number and severity of faults. ^)
//supertype: Means-To-Attain-Dependable-And-Secure-Systems
// Dependability-And-Security-Analysis Fault-Avoidance,
subtype: Validation Verification;
*/
/* developed above in Section "Fault Forecasting":
Fault-Forecasting (^ The means of estimating the present number, the future incidence, and
the likely consequences of faults. ^)
//supertype: Means-To-Attain-Dependable-And-Secure-Systems
// Dependability-And-Security-Analysis Fault-Acceptance,
subtype: Ordinal-Evaluation Probabilistic-Evaluation
Performability Dependability-And-Security-Benchmarks;
*/
System-Life-Cycle is a problematic identifier since "life-cycle"
normally refers to a collection of processes or to a description of a process
but here refers to a process (since processes are declared as subtypes of this category).
Hence, I gave an additional (and more appropriate) identifier to this category. Another
solution would have been to consider System-Life-Cycle as a collection or a description
and use relations different from subtype relations. However, this would have changed the
meaning of the category and the structure of the ontology. Hence, it is better (and simpler)
to assume that the authors simply chose an inappropriate name.
System-Life-Cycle (^ The life cycle of a system consists of two phases: development and use,
which can alternate repeatedly. ^)
= pm#ReSIST_process_in_a_System-Life-Cycle (pm),
subtype: Development-Phase Use-Phase;
Development-Phase (^ A system's development phase includes all activities from presentation of
the user's initial concept to the decision that the system has passed all
acceptance tests and is ready to deliver service in its user's environment. ^)
= pm#ReSIST_process_of_a_development_phase (pm);
Use-Phase (^ The use phase of a system's life begins when the system is accepted for
use and starts the delivery of its services to the users. ^)
= pm#ReSIST_process_of_a_use_phase (pm),
subtype: Service-Delivery Service-Outage Service-Shutdown Maintenance;
Service-Delivery (^ A period of system use during which (correct) service is being delivered. ^);
Service-Outage (^ A period of delivery of incorrect service from a system. ^);
Service-Shutdown (^ An intentional halt of system service by an authorized person or organization. ^);
Maintenance (^ Following common usage, maintenance includes not only repairs, but also all
modifications of a system that take place during the use phase of system life. ^)
subtype: Maintenance-By-Modification Repair,
supertype: #upkeep (pm), //Note: in Wordnet, #upkeep is subtype of #repair
core_domain_object of: acm#K.6.3.1 acm#D.2.7 (pm); //not acm#D2.7 (typo)
Maintenance-By-Modification (^ All modifications of a system that take place during the use phase
of system life. ^)
subtype: Adaptive-Maintenance Augmentative-Maintenance;
Adaptive-Maintenance (^ Adjustment of a system to modifications of its structure (e.g.,
change of hardware, operating systems or system data-bases),
the function being unchanged. ^);
Augmentative-Maintenance (^ Augmentation of a system's function by responding to
customer - and designer - defined modifications (e.g.,
improve performance, add functionality). ^);
Repair (^ A form of maintenance involving the reconstruction or renewal of
part of an existing system. ^)
subtype: Corrective-Maintenance Preventive-Maintenance;
Corrective-Maintenance (^ 1) Repair of a system, its function and structure being unchanged;
2) Fault removal during the operational life of a system. ^);
Preventive-Maintenance (^ Corrective maintenance aimed at removing faults before they
might cause errors during normal processing. ^);
Entity (^ Something that has a distinct, separate existence. ^)
supertype: #self-contained_entity,
subtype: Environment System-Boundary System-Specification (pm) System;
System-Boundary (^ A system boundary is the common frontier between the system and its environment. ^)
supertype: #bounds (pm);
Environment (^ The other systems that have interacted or interfered, are interacting or
interfering, or are likely to interact or interfere with the considered system. ^)
supertype: #environs (pm);
System-Specification (^ A precise description of the system activity that is intended to be
visible at a system's interface with its environment. ^)
supertype: #spec (pm),
core_domain_object of: acm#F.3.1 acm#F.3.1.0 acm#F.3.1.1 acm#F.3.1.4 acm#F.3.1.5;
System (^ An entity that interacts with other entities, i.e., other systems, including
hardware, software, humans, and the physical world with its natural phenomena. ^)
supertype: #system (pm),
subtype: Fail-Controlled-System,
descr: System-Specification (pm),
//Correction of the subtype relation by a "descr" relation (similar to the
// correction made in Section 1). To state this correction formally, instead of "(pm)"
// I could have written: (correction of: `System subtype: System-Specification')_(pm)
object of: System-Life-Cycle (pm);
//Correction of the subtype relation by an "object of" relation
Fail-Controlled-System (^ System failing only in predetermined modes and to acceptable extents, e.g.,
with stuck output as opposed to erratic values, with silence as opposed to
babbling, with consistent failures as opposed to inconsistent ones. ^)
subtype: Fail-Halt-System Fail-Passive-System Fail-Silent-System
Fail-Safe-System;
Fail-Halt-System___Fail-Stop-System (^ System whose failures are, to an acceptable extent, all halting failures. ^);
Fail-Passive-System (^ System whose failures are, to an acceptable extent, all ones that
lead to a stuck service. ^);
Fail-Silent-System (^ System whose failures are, to an acceptable extent, all leading to silence. ^);
Fail-Safe-System (^ System whose failures are, to an acceptable extent, all minor ones. ^);