DEOS

DEOS Project Glossary


DEOS Project Glossary

A,B,C

  • Accountability achievement
    Dealing with system failure by explaining the current status, the cause, and the recovery and future plan clearly to the stakeholders.
  • Agreed requirements
    Requirements that are negotiated among stakeholders through consensus building.
  • Availability
    The ability of a system to maintain a high operating ratio.
  • Black box
    A system or software component whose internal design is unknown and which is integrated to a system based on external specifications only.
  • Cause analysis
    Identification of the cause of failure.
  • Change accommodation cycle
    A cycle of processes to accommodate changes in stakeholders’ objectives or changes in the environment.
  • Closed system
    A system whose boundary, functions, and structure are fixed.
  • Consortium
    A group of organizations or persons who share objectives and intend to cooperate to achieve those objectives.

Back to top

D,E,F

  • D-Aware application
    Application program that is implemented to improve dependability using the APIs provided by D-RE.
  • D-Case
    Method and tool for stakeholders’ agreement.
  • DEOS architecture
    An architecture that supports the DEOS process for a specific area or application. Such an architecture consists of various kinds of tools, a DEOS agreement description database, and a DEOS runtime environment.
  • DEOS process
    The iterative process consisting of the “change accommodation cycle” and the “failure response cycle” to achieve Open Systems Dependability.
  • Dependability
    Ability to deliver services that can justifiably be trusted. This is traditionally defined as the combination of availability, reliability, safety, integrity, and maintainability.
  • Deviated requirements
    Requirements that have deviations from in-operation range.
  • D-Script
    Dynamic responsive script language.
  • Elemental technology
    Technology to realize individual required functions.
  • Elicited requirements
    Identified requirements from each stakeholder’s objectives and needs.
  • Evidence
    Information which supports a claim through an argument.
  • Failure
    Deviation from the range of operations (service level) specified in the stakeholders’ agreement.
  • Failure prevention
    Prevention of system failure involving prediction of system failures and anomalies.
  • Failure response cycle
    A cycle of processes to respond to system failures.
  • Formal verification
    Proof of correctness or incorrectness of programs by formal or mathematical methods.

Back to top

I

  • Incident
    An unfavorable event.
  • Incompleteness
    The property that a system cannot be completely represented.
  • In-Operation
    The state that provides the service continuously meeting stakeholders’ agreement (in the range of service agreement level).
  • In-Operation range
    The allowable operation range of service level that is agreed upon among stakeholders.
  • Integrity
    The ability of a system to prevent improper system and data alteration.

Back to top

L,M

  • Legacy software
    Software whose designers and maintainers are not available for maintenance but which is still built-in and working in a system.
  • Manage
    To solve a problem with efficient use of effort, and develop a state of the system in a favorable direction.
  • Metrics
    Qualitative or quantitative indices to evaluate objects.
  • Model checking
    Software verification technique that exhaustively checks whether a program works correctly by using a system model.

Back to top

O,P

  • Open system
    A system whose boundary, function, and structure change over time.
  • Open Systems Dependability
    The ability to continuously prevent occurrence of open systems failures, to provide appropriate and quick action when such failures occur, to minimize the damage, to safely and continuously provide the services expected by users as much as possible, and to maintain accountability for the system operations and processes.
  • Open systems failure
    Failure that is caused by incomplete and uncertain factors of the system.
  • Ordinary operation
    Daily operation with appropriate periodical inspection and preventive maintenance, including efforts to avoid a repeat of previous failures by performing continuous improvement activities (Kaizen).
  • Ordinarily operated requirements
    Requirements that are implemented and operated ordinarily in the real system.
  • Process
    Steps (phases) of development and operation for systems or services.

Back to top

R

  • Realized requirements
    Requirements that are implemented and embodied in a real system.
  • Reliability
    The ability of a system to perform a specified function for a specified period of time.
  • Responsive action
    Quick and proper response to system failure, to achieve the desired system state.
  • Requirements elicitation
    Identification of requirements from each stakeholder’s objectives and needs through consensus building.
  • Requirements management
    Method of managing requirements based on stakeholders’ agreement.
  • Requirements state management model
    Requirements are managed by the four states that are elicited, agreed, ordinarily operated, and deviated states. The elicited and agreed requirements states are managed at off line, whereas ordinarily operated, and deviated requirements states are managed at online.

Back to top

S

  • Serviceability(Maintainability)
    The ability to efficiently maintain a system through e.g., modification, debugging, and repair.
  • Security
    The protection of a system from external attack that causes degradation of availability, reliability, serviceability, or integrity.
  • Specification description language
    A language which describes the properties that a program needs to satisfy.
  • Stakeholder
    Individual or organization who has a right, share, or interest in the service and/or system in question. For example, users of services or products (the whole society in the case of systems for social infrastructure), providers of services or products, providers of systems (designers, developers, maintainers, operators, and providers of hardware), and certifiers (authorizers) of services or products are stakeholders.
  • Stakeholders’ Agreement
    Consensus among the stakeholders on requirements.
  • System architecture
    A system’s concept, fundamental functions, and structure.

Back to top

T,U,V

  • TAL
    The abbreviation of Typed Assembly Language. Assembly language in which values are annotated with their types, so that type checking is possible.
  • Type checking
    Software verification technique that identifies errors in a program on the basis of the presence of explicitly or implicitly stated variable types.
  • Uncertainty
    The possibility that a property of a system may change and cannot be predicted in advance.
  • Virtualization technology
    Technology for managing computational resources by abstraction of the system, and for enabling the logical partition of computational resources.

Back to top


DEOS Project Abbreviation

  • ADD(Agreement Description Database)
  • DEOS(Dependable Embedded Operating System / Dependability Engineering for Open Systems)
  • D-DST(DEOS Development Support Tools)
  • D-RE(DEOS Runtime Environment)
  • OSD(Open Systems Dependability)

Back to top