Please enable JavaScript.

Coggle requires JavaScript to display documents.

High Integrity Systems Engineering - Coggle Diagram

- - - - Frequency: Frequent -> Probable -> Occasional -> Remote -> Incredible
      - Consequence: Catastrophic -> Critical -> Marginal -> Negligible
      - Risk Class: Intolerable risk -> Undesirable risk and tolerable only if risk reduction is impractical -> Tolerable risk if the cost of risk reduction would exceed the improvement gained -> Negligible risk
    - - Consider the WHAT IF scenarios. Think about the potential hazards that could arise and rate their consequences
      - HAZOP Guidewords
        
        NO or NONE: complete negation
        
        MORE: quantitative increase
        
        LESS: quantitative decrease
        
        AS WELL AS: all intentions + more
        
        PART OF: some of intentions
        
        REVERSE: logical opposite
        
        OTHER THAN: complete substitution
        
        EARLY: earlier than expected
        
        LATE: later than expected
        
        BEFORE: before it is expected
        
        AFTER: after it is expected
      - HAZOP process
        
        For each design item, and for each guideword, interpret the guideword against the design item giving deviations from intended behaviour. For each deviation, determine potential causes, potential consequences, safeguards, risk, and design recommendations
      - Fault Tree Analysis
        
        Analyses when and how hazards can happen, in the context of the system's design. Is deductive, working backwards from hazards (or events that lead to them) to how they can be caused
        
        Node Symbols
        
        Circle = Basic event, an initiating fault requiring no further action
        
        Diamond = Undeveloped event, considered unnecessary or because insufficient information is available
        
        Rectangle = Intermediating event, arising from the combination of other more basic events
        
        Pentagon = Normal event, supposed to occur
        
        Uses
        
        To work out whether/how to change design to guard against causes
        
        To determine causes that the design doesn't guard against
        
        Documentation for safety case
        
        Allow other to check reasoning
        
        Calculate probabilities of hazards arising
- - - - AND ^
      - OR v
      - NOT -
      - IMPLIES =>
      - IFF <=>
  - - - A binary relation is a set of pairs
      - A ternary relation is a set of triples
      - A unary relation is a set of atoms
    - - A total function gives an answer for every argument
      - A partial function is one that is not total
      - Only one output per input
    - - Domain: all items in the set that are valid inputs
      - Range: all items in the set that are valid outputs
      - +: adds relation
      - ++: removes existing relation and adds new relation
      - <: and :> retrieves subset of relations
      - A.B: relation joins
        
        (0, 1) and (1, 1, 1) becomes (0, 1, 1)
        
        Every output of A is tied to every matching input of B
- - - - seq(i)
      - length(seq)
      - append(seq, element)
    - - If we call Search(list, t, index), the following relationships should hold: list[index] = t or index = -1 and t not in range(list)
  - - - Small
      - Unambiguous
      - Abstract from Implementation
      - Machine-Checkable
      - Forces thinking up-front
      - Gets mistakes out of the way early
    - - Requires specialised expertise
      - Might lengthen time to implementation
      - Loads more effort early in the development process
      - Not necessarily well suited to projects with rapidly changing requirements
    - - All programmers know many formal languages
      - Specs are shorter and thus simpler to write than code
      - Specs say only what not how
      - Programs must say both
      - Ordinary programmers not trained to write an read formal specs
- - - - WHO (subjects) can access WHAT (objects) in which WAYS (permissions: read/write/execute)
      - An access control matrix defines the protection state at any instant in time
      - Two obvious choices for storing protection state over access control matrix
        
        Store individual columns with each object
        
        Each column is called the object's access control list
        
        Defines the subjects that can access each object
        
        Store individual rows with each subject
        
        Each is called the subject's capability list
        
        Defines the objects each subject can access
        
        More common in research
      - Mandatory vs Discretionary
        
        Discretionary Access Control
        
        Users can make access control decisions such as delegating their access to other users
        
        Mandatory Access Control
        
        Enforcement of administrator-defined policy
        
        Users cannot make access control decisions (except those allowed by mandatory policy)
        
        Can prevent untrusted applications running with user's privileges from causing damage
        
        Common in areas with global security requirements, less so for general purpose settings
      - Bell-LaPadula Model
        
        MAC Policy/Mechanism
        
        Every object is assigned a classification which is ordered
        
        Every subject is assigned a clearance which is the highest classification they're allowed to learn
        
        Rules
        
        Simple Security Property ("no read up"). s can read o if clearance(s) >= class(o). S can read U,C,S but not TS. Standard Confidentiality
        
        *-Property ("no write down"). s can write o iff clearance(s) <= class(o). S can write TS, S but not C, U to prevent accidental or malicious leakage of data to lower levels
        
        Boebert's Attack
    - - ord/first
      - ord/last
      - ord/next
      - ord/prev
      - ord/nexts
      - ord/prevs
- - - - Runtime Checks for Signed overflow, array index-out-of-bounds, accessing unallocated memory, range errors
      - Turns heisenbugs into crashes
- - - - Programs in a safe subset can be compiled and debugged using existing toolchains
      - Programmers don't need to learn a new programming language
      - Resulting programs far more tractable to automatically analyse and verify
  - - - Dynamic Memory Allocation
      - Tasks
      - Goto
      - Access Types
      - Side-effectful expressions and functions
      - Exception Handling
    - - Annotations
  - - - Conformance to SPARK restrictions
      - Unused assignments
      - Uses of uninitialised data
      - Missing return statements
      - Violations of flow contracts ("Depends")
  - - - Conformance to SPARK restrictions
      - Uses of uninitialised data
      - Possible run-time errors
      - Functional contracts ("Pre/Post" conditions)
- - - - Non-malicious
      - Byzantine
    - - Independent
      - Correlated
    - - Permanent
      - Intermittent
      - Transient
  - - - Hardware: multiple processors, duplicate hardware
      - Software: multiple implementations
      - Information: error checking and error correcting codes
      - Time: retrying tasks, transaction rollback
    - - Items are sufficiently equal when they are within some small distance epsilon of each other
      - Voting Algorithms
        
        Majority Voting
        
        If a set is the largest set and it holds more outputs than half the total outputs
        
        Generalised k-plurality voting
        
        If a set is the largest set and it meets the plurality constraint (size > k)
        
        Generalised median voting
        
        Repeatedly eliminate the furthest two elements
    - - With N components the system can tolerate (N-1)/2 failed components
      - With N components the system can detect N-1 failed components
    - - Faulty units should be purged unless fault is transient
      - Self purging: unit compares itself to voted output and purges itself if different
      - Sift-out redundancy: Take all pairs of units, controller disconnects units that disagree with majority
  - - - N-version programming
        
        Execute multiple instances of the software and vote on the output.
        
        Requires multiple software versions with independent designs, independent implementations, and independent software engineering teams
        
        Common Mode Failures
        
        Faults in Spec
        
        Similarity of development languages and environments
        
        Similarity of algorithms
        
        Similar training of software engineer teams
      - Recovery Blocks
        
        If version 1 fails, go to version 2 and so forth. This is determined by acceptance tests which is sometimes a sanity check. This test also requires diversity
        
        Better than N-version programming
        
        Alternate versions can be simpler
        
        Increased design diversity in alternate versions
        
        Increased reliability in alternate versions
        
        Cheaper