(Re-)presentation of the ReSIST ontology in FL

Dr Ph. MARTIN, October 2008

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.


Table of contents

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, ...)



1. Abbreviations, Ontology and Domain

user resist;  //"resist" is the default author of the relations below
unprefixed terms are key names;  //this allow relation names not to be prefixed
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



2. Attributes

pm#dependancy_or_information_security_attribute
  subtype:  Dependability (pm)   Security (pm);
//supertype:  pm#security_attribute;  //stated elsewhere


2.1. Dependability

   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. ^)
           supertype:  #dependability,
           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. ^)
           < #safety,	
           core_domain_object of:  acm#K.4.1.3;

         Robustness (^ Dependability with respect to external faults. ^)	
           core_domain_object of:  acm#G.4.6;




2.2. Security

   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). ^);



3. Particular Roles of some States or Processes


3.1. Threats To Dependable And Secure Systems

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);





3.1.1. Errors

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. ^);


3.1.2. Failures

      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

3.1.2.1. Consequences, Detectability and Consistency of Failures

      /* 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. ^);

3.1.2.2. Phases of Failure

      /* 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. ^);

3.1.2.3. Domains of Failure

      /* 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) ^);


3.1.3. Faults

      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;







3.1.3.1. Faults Categorized According To Intent Or Objective

      /* 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. ^);

3.1.3.2. Faults Categorized According To Other Characteristics

      /* 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. ^);



4. Processes (Fault Acceptance/Avoidance)

/* 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); 
*/


4.1. Means To Attain Dependable And Secure Systems: Fault Acceptance/Avoidance

   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);
     = pm#Fault_Acceptance/Avoidance___Fault_Forecasting/Prevention/Removal/Tolerance
      //in the RDF+OWL source, the 4 indirect subtypes are directly listed instead of these 2 direct subtypes




4.1.1. Fault Acceptance: Fault Tolerance/Forecasting

      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;


4.1.1.1. Fault Tolerance

         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. ^);

4.1.1.1.1. Error Detection, Confinement and Recovery
            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. ^);

4.1.1.1.2. Fault Tolerance_Coverage
            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. ^);



4.1.1.2. 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,	
           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. ^);



4.1.2. Fault Avoidance: Fault Prevention/Removal

      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. ^);




4.2. Dependability And Security Provision (Fault Prevention/Tolerance)

   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;
      */



4.3. Dependability And Security Analysis (Fault Removal/Forecasting)

   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;
      */



4.4. Processes of the System Life Cycle

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. ^);




5. Entities (Environment, System, ...)

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. ^);




Dr. Philippe A. MARTIN