DEOS Project Glossary

• A,B,C
• D,E,F
• I
• L,M
• O,P
• R
• S
• T,U,V

DEOS Project Abbreviation

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.

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.

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.

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.

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.

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.

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.

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.

• 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）