DEOS Project

White Paper© 2010 Japan Science and Technology Agency

DEOS-FY2010-WP-02E

JST-CREST
Dependable Operating Systems for Embedded Systems
Aiming at Practical Applications－ DEOS Project －DEOS: Dependable Embedded Operating System

White Paper

Version 2.0a
2010/12/01
DEOS Project Research Supervisor
Mario Tokoro(Sony Computer Science Laboratories, Inc.)

Japan Science and Technology Agency

© 2010 Japan Science and Technology Agency

White Paper

DEOS ProjectPreface to Version 2.0a
It has been one year since we published the DEOS Project White Paper Version 1.0 on September
1, 2009. The project is progressing in accordance with the plan described in the White Paper
Version 1.0, and implementation of the technology as well as software development have started.
We are pleased to publish this second version of the DEOS Project White Paper to present our recent
progress.
Changes to chapters of Version 2.0a from Version 1.0:
Version 1.0

Version 2.0

Chapter 1

Background

Chapter 1

Background

Chapter 2

Dependability

Chapter 2

Dependability

Chapter 3
Chapter 4

Phases of DEOS Processes
Project Direction

Chapter 5

Major Research and Development
StatusResearch and Development
Organization

Chapter 3
Chapter 4

Chapter 5
Chapter 6
Chapter 7

Chapter 8

Page 2

Project Direction
Items for Research &Development

Research andDevelopment
Organization
Roadmap
Issues and Concerns

Chapter 7
Chapter 8

Appendix

Chapter 9
Chapter 10

Chapter 6

Roadmap
Further Issues for Practical
Applications
References
Appendix

Version 2.0a

Major
difference
Part
added
LittlechangeNew
RenewedMergedinto
Chapter 4
New
Part
added
RenewedRenewedRenewedRenewed2010/12/01

10/09/2010

White Paper Version 2.0a

DEOS ProjectContributors
Kenji Kono
Jin Nakazawa
Hideyuki Tokuda
Hiroshi Yamada
Hajime Fujita
Yutaka Ishikawa
Yutaka Matsuno
Toshiyuki Maeda
Yasuhiko Yokote
Taisuke Boku
Toshihiro Hanawa
Shuichi Oikawa
Mitsuhisa Sato
Kimio Kuramitsu
Midori Sugaya
Tatsuo Nakajima
Yoichi Ishiwata
Satoshi Kagami
Yoshiki Kinoshita
Toshinori Takai
Makoto Takeyama
Ichiro Yamaura
Shigeru Matsubara
Tomohiro Miyahira
Kiyoshi Ono
Hiroki Takamura
Makoto Yashiro

Keio University
Keio University
Keio University
Keio University
University of Tokyo
University of Tokyo
University of Tokyo
University of Tokyo
University of Tokyo
University of Tsukuba
University of Tsukuba
University of Tsukuba
University of Tsukuba
Yokohama National University
Yokohama National University
Waseda University
National Institute of Advanced Industrial Science and Technology
National Institute of Advanced Industrial Science and Technology
National Institute of Advanced Industrial Science and Technology
National Institute of Advanced Industrial Science and Technology
National Institute of Advanced Industrial Science and Technology
Fuji Xerox Co. Ltd.
Dependable Embedded OS R&D Center, JST
Dependable Embedded OS R&D Center, JST
Dependable Embedded OS R&D Center, JST
Dependable Embedded OS R&D Center, JST
Dependable Embedded OS R&D Center, JSTThis project is supported by CREST, Japan Science and Technology Agency

2010/12/01

Version 2.0a

Page 3

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

Table of Contents
1
2

Background
Dependability

67

2.1 Brief Historical Review..................................................................................................... 7
2.2 Environment of Embedded Systems and Requirements ................................................ 8
2.3 Open Systems Dependability ......................................................................................... 10
2.4 DEOS Process ................................................................................................................. 12

3

Phases of the DEOS Process

13

3.1 System Change-Requests based on Stakeholders’ Agreement..................................... 13

3.2 Design, Implementation, Verification, and Testing...................................................... 14
3.3 Achievement of Accountability....................................................................................... 14
3.4 Failure Prevention.......................................................................................................... 15
3.5 Responsive Action ........................................................................................................... 16
3.6 Cause Analysis................................................................................................................ 17
3.7 Normal Operations ......................................................................................................... 17

4

Project Direction

18

4.1 Project Goal ..................................................................................................................... 18
4.2 Project Objectives ........................................................................................................... 18
4.3 Realizing Open Systems Dependability ........................................................................ 18
4.4 Project Deliverables ........................................................................................................ 22

5

Major Research and Development Status

23

5.1 Framework ...................................................................................................................... 23
5.2 Dependability Metrics and Stakeholders’ Agreement Processes ................................. 25
5.3 System Monitoring and Evidence Analysis................................................................... 27

5.4 Security ........................................................................................................................... 30
5.5 Virtualization and its Application ................................................................................. 32
5.6 Systems Software Verification ....................................................................................... 34
5.7 Dependability Measurement Tools and Test Tools....................................................... 36
5.8 Process and International Standards ............................................................................ 38
5.9 Research and Development Activity Results ................................................................ 40

6
7
8

Research and Development Organization
Roadmap
Further Issues for Practical Application

41
42
43

8.1 Handling of Intellectual Property Rights and Copyright ............................................. 43

8.2 Open Systems Dependability Consortium ..................................................................... 43

9 References
10 Appendix

44
45

10.1

Dependability Obstructions..................................................................................... 45

10.2

Related Standards and Organizations.................................................................... 46

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

10.3

DEOS Project Terminology ..................................................................................... 48

10.4

DEOS Project Members ........................................................................................... 50

2010/12/01

Version 2.0a

Page 5

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

1 BackgroundToday’s embedded systems such as mobile information equipment, office informationequipment, home
appliances,andcarinformation
systemsarenolongerused as independent stand-alone devices, but are connected to a network as part of a large system.
Services are provided to these embedded systems through the network; making these devices usefulto people all over the world, and bringing convenience and comfort into the lives of the people insocieties where such systems are ubiquitous. Many of these embedded systems are increasing incomplexity and scale in order to meet the diverse and sophisticated needs of their users. In thedevelopment of these systems, software, which has been used for some period of time and without
detailed specifications, or which have been created by other developers, are used frequently being
treated as a black box. Changes to external factors such as the modification of other systems that areconnected via a network occur frequently. The maintenance and management of these systems
involve specification changes while in use. Those factors of today’s embedded systems make it
impossible for developers and operators to know every detail of the system. As such, it is becoming
more difficult to ensure the reliability and availability of these embedded systems. In addition, fatalsystem problems such as crashes caused by viruses, and information leaks due to unauthorizedaccess continue to occur. It has become a major responsibility of product and service providers totake appropriate action against these threats, always ensuring user safety and security when using
these products and services.
Recently many social infrastructures have experienced failures in their systems. These took
considerable time to repair in some cases, and services were suspended until recovery, which caused
considerable loss of benefits to users. This damage to service providers is not limited to the cost ofanalysis of the cause of the failure and work for recovery, but also includes the loss of businesschances while the system is down and the loss of reputation with the public. The analysis of those
failures shows that major causes of these failures include the system being developed without
sufficient understanding of the behavior of all of the components, or the system being too
complicated for every detail of the behavior of the system to be anticipated and controlled. Somesystem failures are attributable to insufficient planning by the designers and programmers. In
some cases, the number of users, transactions, data volume, or coverage of the system exceeded theinitial design limit, which led to failure of the systems. Changes or the addition of system functions
after the launch of services to adapt to changes in the requirements of users caused the failure insome cases. These cases indicate that modern computer systems should not be assumed as asystem whose function, architecture, and system boundary are fixed in both the way they aredesigned and implemented and the way they are used. They should be handled as systems which
grow and change over time. It is expected that those characteristics will get stronger in the future.
Up until now, most development processes of embedded systems have adopted the common
practice of creating a reliable development plan in advance, determining in detail the product orsystem specifications, and going through the long cycle of design, implementation and verification. It
has become a standard practice to perform the “PDCA” cycle to enhance the special advantages (aswell as function, performance, and quality) of individual products as well as the whole system. This
process is quite effective for the development of products or systems which are not connected to alarger network and which have specifications and behavior that are quite defined and predictable atthe beginning of development. However, as mentioned earlier, functions, structures, and boundaries
of systems change over time, and the development and operation need to be performed under thecondition that it will be nearly impossible to write complete specifications beforehand, envision acomplete development plan, and correctly predict what all its network connections will be. For thiskind of system, the management process for developing specifications based on a predicted range ofconditions and for updating these specifications repeatedly by gathering feedback during the whole
lifecycle is very crucial. Elemental technologies and system architecture to enable this process need
to be developed [18]. The development process of a system suited to changing environments will not
be the legacy “waterfall” model which requires completeness in each development phase, but process

Page6

Version 2.0a

2010/12/01

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

which adopts new software components and quickly implements the required functions in order toadjust to new requirements. The process of prototyping or trial production in actual environments,
and improving the functions and quality of the systems with feedback from users, is demanded. In
other words, we need to establish a new process in which both the feedback loops of the development
process and the feedback loops of the operation and maintenance process move forward, while thesedual loops interact with each other.
The above discussion indicates that dependability attainment technology for systems with fixed
functions, structures, and boundaries is no longer sufficient to achieve and to improve a system’s
dependability. There is a need to establish a method to build and operate dependable systems thatare based on new concepts and technologies [1, 4, 5, 6 and 12]. In this paper, the concept of “Open
Systems Dependability” is proposed to meet those new requirements, and then the technologies, thearchitecture, and the processes to realize this concept are described.

2 Dependability
2.1 Brief Historical Review
In the 1960's, the construction of a Fault Tolerant Computer was proposed to support real-time
computing and mission critical applications. Active discussion of this topic has been ongoing sincethen [15 and 19]. As a result of this discussion along with the increase in scale of hardware andsoftware and with the spread of online services, a concept called RAS has been developed which
integrates resistance to failures (Reliability), maintenance of a high operating ratio (Availability),and quick restoration during a malfunction (Serviceability or Maintainability), with an emphasis onerror detection and system recovery [8 and 14]. In the latter half of the 1970's, to this concept wasadded the preservation of data consistency (Integrity) and the prevention of unauthorized access toconfidential materials (Security), for RASIS, an extension of RAS that has served as a standard forevaluation. In 2000, the idea of Autonomic Computing was proposed to ensure dependability incomplex systems connected by networks with autonomic action, in the same way that the autonomic
nervous system works in the human body [9, 10, 11, and 16].
Changes in approaches taken to ensure reliability are reflected in international standards.
International Safety Standards ISO 13849-1 (EN954-1) and Safety of Machinery - Electrical
Equipment of Machines Standards IEC 60204-1 can handle simple systems, subsystems, and parts,
but are not sufficient to deal with systems that include software. Functionality Safety Standards
IEC 61508 were established in 2000 out of necessity for a safety standard for systems that include
software. In IEC 61508, a system malfunction is divided into "random hardware failure" and"systematic failure". The probability of
random hardware failure is calculated bymonitoring malfunctions due to thedeterioration of parts; while systematic
failures, caused by incorrect system design,development, production, maintenance, andoperation, are to be kept from exceeding
allowed target values through softwaredevelopment, and a verification process suchas the V-model, and the documentation of all
operations based on the safety lifecycle.
Fig.1. Dependability and Security
Systems are categorized according to mode ofoperation: low demand mode or highdemand/continuous mode. The target failure limit for each mode is defined and managed as the
Safety Integrity Level (SIL). The requirements of 4 stages from SIL1 to SIL4 are also defined (with
SIL4 requiring the highest safety integrity). With IEC 61058 as the base standard for softwaresystems, machinery-related IEC 62061, process-related IEC 61511, nuclear-related IEC 61513,

2010/12/01

Version 2.0a

Page 7© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

railway-related IEC 62278, etc. were established, and for automotive systems, a DIS (Draft
International Standard) of ISO 26262 was issued in June 2009 and the final version is expected to beissued in 2011.
Efforts are continuing to produce a single definition of dependability which integrates different
conceptions. In 1980, a joint committee of IFIP WG10.4 studying Dependable Computing and Fault
Tolerance and IEEE TC studying Fault Tolerant Computing was formed, and they initiated a study
on "The Fundamental Concepts and Terminologies of Dependability". The details and results of thesubsequent investigation were compiled in a technical paper that was published in 2004 [2, 3]. In
this paper, dependability and security are defined using the terms given in Figure 1. However, inorder to provide solutions to problems of complex modern systems with the functions, the structures,and the boundaries changing over time, assuming those factors are fixed and simply dividing andanalyzing systems into these attributes and dealing with each attribute separately is insufficient.

2.2 Environment of Embedded Systems and Requirements
As it has already been described,
embedded systems have become much moresophisticated and complex in order to meetthe various needs of users; and they havegrown larger in scale. The softwarearchitecture of embedded systems isdetermined, designed, and implemented
basedon
requirement
specifications.
However, to shorten the development period
and to lower development costs, the practiceof using “black box” software, such as
existing software or software provided byother companies, has increased. Moreover,
specification
updatesforfunction
improvement and change occur while thesystem is in operation. In this situation,
amendments of the software are downloaded
and new functions are added through the
network. In this kind of environment, it is
becoming exceedingly difficult for designers
and developers to know each and every detailof the system throughout its lifecycle (Figure
2).

Network

ChangeRequirements

Fig.2. System Components and Services

Network

Many of the modern embedded systems
today are used with other systems to which
they are connected via a network. In this case,users of the embedded systems utilize
Fig.3. Services through Networks with Humanservices that a single domain (consisting ofInteractions
networked systems) provide through the
network. A single service domain also connects and interacts with other domains at different levels,and it is possible for services and the interface specifications of other service domains to undergochanges or to be discontinued. In this environment, the boundary of the system or service domain
becomes unclear. Furthermore, there is the possibility that system designers and developers,
operators and users may commit unintended errors. Likewise, with the spread of networks,
unknown services are provided through the network expanding the possibility of unknown andunexpected interactions to occur; raising the concern that the system may be attacked on purpose

Page 8

Version 2.0a

2010/12/01

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

with malicious intent. For these reasons, the advent of networking has made predictability much
more difficult to attain (Figure 3).
The analysis and classification of the cause of system failures discussed above, with considerationof the systems and services from both development and operation standpoints, will lead to thefollowing factors.
zz< Incomplete Specifications and Implementation, and Difficulty of Understanding the
System>It often happens that the initial requirement specifications become inadequate, the system’s
behavior becomes difficult tofully understand, andguarantees at the time of
shipment cannot be made.
(Fig.4). Specifically, there is
likely to be:
z An error or omission in thespecification, design
implementation, or testing,caused by discrepancies incharacterizations of thesystem during therequirement development
phase, specification phase,
design phase,
implementation phase, andtesting phase, or by an error
Fig.4. Incomplete Specifications/Implementation and thein the documentation
Difficulty of Understanding the Systemz An error or omission in
specification, design implementation, or testing, caused by the difficulty of understanding
the whole system, particularly its software, due to its complexity and sizez Poor system design, inadequate capacity of the planned system, demands upon
programmers surpassing human capabilityz An error in administration, operation, or maintenance cased by the difficulty ofunderstanding the whole system, particularly its software, due to its complexity and sizeo An error in updating or
amendment procedureso Expiration of licensez Use of “black box” components
or legacy codes based on theirexternal specifications,
without knowledge of theirinternal design< Uncertainty about Usage
Environment, and Difficulty in
Predicting System Behavior>
Changes in the usage environmentand configuration throughout the
lifecycle of the system make it
difficult to completely predict the
behavior of the system while stillFig.5. Uncertainty at Usage Environment, and Difficulty inin the design phase. (Fig.5)
Predicting System Behavior
Specifically, there are:z Changes in user’s expectations

2010/12/01

Version 2.0a

Page 9© 2010 Japan Science and Technology AgencyzzzWhite Paper

DEOS Projector capability during the maintenance and operation phases – changes in requirements
and level of requirements, operation capability, or skill/experience/negligence of
operators.
Unexpected usage changes, such as those brought about by the significant increase inusers, or number of units, as well as by changes in economy.
Update or alteration of a component's function and system configuration on a system inoperation through manual operation on through network.
Specifications of services and components that are being used are corrected and updated
via the network; unexpected network connections; and, intentional malicious attacks andintrusions through external entities.

Today’s embedded systems with ever changing functions, structures, and boundaries must obtaindependability and be able to deal with the inherent incompleteness and uncertainty. We cannot
create a flawless system that can already handle all possible scenarios that could take place in the
future. Failure, therefore, cannot be completely avoided.
Contemplation of this situation has led people to make various definitions of “dependability”. The
following are examples of such definitions: “The continuing state where no failures or malfunctions occur, or where the situation isgrasped immediately when abnormalities do occur, the subsequent situation is predicted, andsocial panic and catastrophic breakdown is prevented, at reasonable cost. ” [7] “The capacity for the services offered by the system to be maintained at a level acceptable forthe user even if various accidents occur.” [17]2.3 Open Systems Dependability
As we have discussed so far, we need to deal with the dependability of systems of which functions,structures, and boundaries keep changing over time. Systems with those characteristics are called
Open Systems, in contrast to Closed Systems which assume fixed functions, structures, andboundaries that stay the same through the life of the systems.
The characteristics of Closed Systems are;z The boundary of the system is
Closed Systems
Open Systems
definable.
z The interaction with the outer
Subsystem
world is limited, and the system
Subsystem
Subsystemfunctions are fixed.
Subsystemz The subsystems or components of
Subsystem
Subsystem
the system are fixed and their
Subsystem
Subsystem
relationship does not change over
Subsystem
time.
Subsystem
Subsystemz The system is observable from
Subsystem
outside of the system.
z Reductionism is applicable (a wholesystem is dividable into subsystems
Fig.６. Closed Systems and Open Systems
or components, and the behavior of
the whole system can be understood by understanding all of the subsystems or thecomponents).
On the other hand, the characteristics of Open Systems are;z The boundaries of the systems change over time.
z There is interaction with the outer world, and the system functions change over time.
z The subsystems or components of the system and their relationship change over time.

Page 102010/12/01

Version 2.0a

DEOS Projectzz

White Paper© 2010 Japan Science and Technology Agency

An observer of a system is inherently a part of the system, and the system is not observablefrom outside of the system.
Therefore, reductionism is not applicable.

The computer systems we need to manage today hold the characteristics of opens systems. Thatis, those systems are connected to a network and the boundaries of the systems are unclear andchange over time. Requirements for the functions and performance of these systems fromstakeholders such as users of the services, providers of the services, and providers of the systems,
etc., change, and the functions and performance of the systems change over time. Replacement orchanging the components of the system occurs consistently for performance improvement, bug fixes,
expiration of maintenance, and expiration of contracts, and the relationship of the subsystems orcomponents of the system keep changing.
It may be possible to assume a system as a closed system at a specific time, which means there is
no change for a certain period of time, and then consider the lifecycle of the system by accumulatingthese periods of time. In this case, the function, the structure, boundary, and specifications of thesystem need to be defined at each time, and the design, verification, and the testing of the system aredone based on the specifications, repeating this process for each period of time in the lifecycle.
However, it is extremely difficult to separate the phases that the system is fixed and in operationand the phases where the system is in the process of modification. Usually it is most important thatthe service and operation of the system is continued, even with changes to the system on-going. To
approach this situation, we should focus on the “ever-changing systems” and establish the concept of
dependability focusing on the continuity of services and business by managing the continuously
changing systems. Our approach is to consider the concerned systems as open systems and to focus
on how we should improve dependability throughout the lifecycle of the systems. Based on our
discussion thus far on the characteristics of modern embedded systems, we define Open Systems
Dependability with the following description:
Functions, structures, and boundaries of modern embedded systems change over time. Hence
incompleteness and uncertainty may result in failures in the future, and they are inherent toembedded systems (factors in open systems failure). Open Systems Dependability is the ability tocontinuously prevent the said factors from causing failure, to take appropriate and quick action
when failures occur to minimize damage, to safely and continuously provide the services expected byusers as much as possible, and to maintain accountability for the system operations and processes.
“Open Systems Dependability” does not conflict with the “dependability” that has been studied,discussed and classified by many researchers. Until now, technologies for improving the safety andsecurity of systems have been researched, discussed and developed with a focus on incidental andintentional faults. Our approach is to improve the dependability of systems by minimizing thefactors that specifically cause open systems failures (this can largely be done during the
manufacturer’s development phase before shipment) and minimizing the damage due to open
systems failures (this is largely done during the operation phase after shipment), concentrating on
open systems failures resulting from incompleteness and uncertainty. Indeed, “Open Systems
Dependability” complements and further enhances “closed systems dependability”.
In summarizing the discussion in the previous paragraphs, Open Systems Dependability isdefined as “providing services continuously by managing unpredictable failures on ever-changing
systems”. “Managing” means to assure sustainability of services with the best effort, which is mostimportant to both users and providers of the services. The continuity of business which is assured
as a result of continuity of service is also important for service providers.

2010/12/01

Version 2.0a

Page 11© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

2.4 DEOS Process
To achieve open systems dependability, that is to achieve continuity of services on the open
systems in which functions, structures, and boundaries of the systems keep changing over time, we
concluded that an approach from the process perspective is required. This is the process of thecontinuous improvement of dependability. We call this process the DEOS Process. We identify
two cycles in this process; one is the “requirements/environment change accommodation cycle” which
is a cycle to adapt the system according to requirements or environmental change, and the other is
the “failure reacting cycle” which is a cycle to take immediate action and fix failures that occur in thesystem in service and operation. In summary a DEOS Process is a process to continuously improvethe dependability of computer systems, and consists of 2 cycles (Fig.7), namely
1.
Requirements/Environment Change Accommodation Cycle, and2.
Failure Reacting Cycle.
The Requirements/Environment Change
D-CaseDEOS Process
Accommodating Cycle begins is triggered by
the change of requirements of stakeholders
D-Casegrowth cycle
or by a change to the system’s environment.
Requirement/Environment
Changeaccommodating
cycle
Examples of requirements changes are
System change requests
requests to change the content or the quality
Design Implementation Verification
Test
based on stakeholders’agreementof services or to improve the function or the
performance of the system, and requests tochange the services or systems to meet
Failure reacting
cyclechanges in regulations or standards. On
Achievement ofaccountability
the other hand, examples of environmental
Normaloperationchanges are changes to network function or
performance, changes raised by the changeof services provided by other systems in theFig.7. DEOS Process
network, changes caused by hardware
change, changes caused by the expiration ofsoftware licenses or maintenance contracts, and the changes required to cope with an increase inusers. To accommodate those changes, the cycle, to get agreement of these change by the
stakeholders, to go through design, implementation, verification, and testing, to describe the change
and improvements to the users, and then to resume normal operation, begins.
Stakeholders’requirements/
SystemenvironmentchangesCause analysis

Responsive action

Failure prevention

Anomaly detection/
Unexpected failure
happenThe Failure Reacting Cycle requires prompt action. The cycle is triggered by failure prediction orby the occurrence of a fault or error, and in some cases is triggered by a failure. In the phase of
failure prevention, responsive action, andcause analysis. Preventive action is taken if
possible. In the case that a failure hastoccurred, an immediate fix must be taken. It
en yclemis crucial to take accountability, that is an
on g cvir atinndexplanation to service and system users
E
nt/ moemabout the status of the failure, the immediateem cou i r e acaction taken, the plan for long term actionq
Re angand a permanent fix, and so on, and then theChservice and system go back to normal
operation. The long term action and theleyccpermanent fix, with the result of root causeng
cti
analysis, are agreed to be implemented byarestakeholders. That is, this initiates the
ure
l
i
Fa
Requirements/Environment Change
Accommodating Cycle. Normal operation
Fig.8. Image of the DEOS Process double helix inincludes preventive maintenance, daily
space-time
improvement action (Kaizen), and preventive

Page 122010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

dry runs to be done before or after daily service.
The characteristics of the DEOS process are; 1)it consists of the two cycle, 2) it contains twophases, “system change-request based on stakeholders’ agreement” and “achievement ofaccountability” . “D-Case” is used in the DEOS Process to support stakeholders to understandchange-requests brought up among themselves, to examine and discuss each interest related to thechange-request, and to reach agreement on the change to be made. As it has already been described,
the DEOS Process implies that the system grows up over time, and the process forms into a double
helix in space-time. Figure 8 shows the image of the double helix.

3 Phases of the DEOS Process
It has already been described that the DEOS Process is a process to continuously improve thedependability of open systems, and consists of the 2 cycles requirements/environment change
accommodating cycle, and failure reacting cycle. The concept and required actions in each phaseare discussed in this chapter.
The phases in the “requirements/environment change
accommodating cycle” are “system change-requests based on stakeholders’ agreement” and “design,
implementation, verification, and testing”, and “achievement of accountability phase”. The phases inthe “failure reacting cycle” are “failure prevention”, “responsive action”, “cause analysis”, and again“achievement of accountability phase”. It is assumed that continuous dependability improvement
action such as preventive maintenance, daily improvement action (Kaizen), preventive dry runs
before or after the daily service, and education to engineers and operators are implemented innormal operation.

3.1 System Change-Requests based on Stakeholders’ Agreement
When requirements from the stakeholders change (including new requirements), the environmentof the system changes, or a change in the system is required as a result of cause analysis of a failure,changes are thoroughly described as written specifications without exception so that all the
stakeholders understand the change without any misunderstanding. Requirement engineering
addresses the method of describing the requirements and the tools to support the method, whichshould be fully utilized in this context.
Here the stakeholders, we assume in thiswhite paper, are as listed.
z Users of services or products (the wholesociety in the case of systems for social
infrastructure),z Providers of services or products,z Providers of systems;¾ Designers and developers,¾ Operators and maintainers,¾ Providers of hardware, andz Certifiers (Authorizers) of services or
products.

D-CaseTop
Structure

Sustainability ofServices

Goal

Consider the DEOS
process

Strategy

Requirement/Environment
Change accommodating cycle

Failurereacting cycle

Consider the stages ofRequirement/Environment
Change accommodating cycle

Consider the stages ofFailure reacting cycle

System change requests
based on stakeholders’agreement

Design/Implementation/Verification/Test

Achievementof
accountability

Failureprevention

Responsive
actionSub-GoalCauseanalysis

Strategy

Achievementof
accountability

In order to realize accommodation to change
it is essential for all of the stakeholders tocorrectly understand the requirements,, to findFig.9. D-Case Top Structure
solutions to possibly conflicting requirements,
and to make decisions on how to implement andwith what schedule. For this “description language or notation for stakeholders to share
understanding” or “executable description language or notation for the agreement of requirements

2010/12/01

Version 2.0a

Page 13© 2010 Japan Science and Technology Agency

White Paper

DEOS Projectand specifications” is required to realize
the process described.
A set of theconcept, method, and tool called D-Case is
D-CaseBottomunder study and development in the DEOS
Structureproject.
D-Case uses GSN (Goal
Structured
Notation),
which
is
a
description notation similar to Assurance
Sub-Goal
Case. Assurance case is described in a tree
structure. The tree structure itself is not
Evidence
substantial, but the strategy to decide how
to branch from a node, the construction, or
the condition of the branch, which are
Sub-Goaldescribed as a DEOS process, is significant.
The top structure of D-Case which
Evidencedescribes Open Systems Dependability will
be as shown in figure 9. The goal will be
discussed and broken into sub-goals in theFig.10. D-Case Bottom Structure
process of D-Case writing, and finally eachnode is connected to corresponding
evidence. The bottom structure of D-Case will be as shown in figure 10.

3.2

Design, Implementation, Verification, and TestingThis phase corresponds to the so-called design and development phase. There has been a lot of
research and development in this area, and various methods and tools have been proposed. Useful
methods and tools should be utilized in this phase for open systems as well. There are some specificrequirements for this phase to improve open systems dependability.
zzDesign and implementation technology¾ Describe the requirements correctly and document as specifications¾ Design a system based on the specifications without mistakes¾ Implement the design without mistakes
Verification and testing technology¾ Test the implemented system correctly according to the specifications¾ Detect software errors using formal method¾ Verify the system on a simulator¾ Measure system margin by injecting faults or abnormal conditions¾ Compare the system with expected normal status or known standard levels¾ Measure the dependability indices¾ Verify the validity of the dependability indices3.3 Achievement of Accountability
Service providers, providers of social infrastructure, and commodity producers in particular havethe responsibility to disclose and explain to service consumers, users of products, and society ingeneral about occurrences and causes of failures, expected recovery time, and to amend theirdevelopment and operation processes and procedures in routine operations so as to prevent such
failures from occurring in the future. Carrying out these activities satisfies not only the social
responsibility of the providers, but also creates the consensus required to run social infrastructure,

Page 142010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

and protect the brand of the service or system providers. It also helps to gain trust from service
consumers and society,, and to protect their profits.

(1) Accountability in requirements/environment change accommodating cyclezzDescribing changes of requirements¾ Investigation into the stakeholders’ requirements¾ Processes and status of stakeholders’ agreement¾ Content of services, system functions, schedule of service offerings, and terms andconditions of the offering, after the accommodation of the change¾ Status of compliance to laws and standards
Describing change of environment¾ Investigation into the environment changes¾ Processes and status of stakeholders’ agreement¾ Content of services, system functions, schedule of service offerings, and terms andconditions of the offering, after the accommodation of the change¾ Status of compliance to laws and standards(2) Accountability in failure reacting cyclezzDescribing status at failure prevention or at failure occurrence¾ Records of system monitoring and evidence of system behavior¾ Status of failure prevention¾ Status of responsive action, temporary fix, and service recovery schedule¾ Status of cause analysis¾ Schedule for root cause analysis and permanent fix implementation¾ Processes and status of stakeholders’ agreement¾ Records of design and development, operation and maintenance, and education ofengineers¾ Records of education of personnel related to the services
Describing processes and status of daily business and system operation¾ Processes of reaching stakeholders’ agreement and of maintenance of the agreement(D-Case to be described later)¾ Compliance with the DEOS Process¾ Education and processes related to personnel for system design, development, operation,and maintenance

Systems used to provide services need to have the capability to support the achievement ofaccountability as described above.

3.4 Failure Prevention(1) Prediction of failures and detection of anomalies
We will be able to establish a procedure to prevent failures if we can predict them while systems
are in operation by detecting some anomalies in advance which are potential causes of failure. The
action taken will depend upon how soon we can predict the failure. The earlier we can predict it,
the more valuable the prediction is for the system or service providers. For instance, we may beable to prevent the failure if we can predict it a few minutes before. Even if we cannot prevent itfrom occurring, we may be able to minimize any damage caused by the failure. If we predict a
failure a few seconds before its occurrence, we may be able to prevent the entire system fromshutting down, even though it may be impossible to prevent partial failure. Alternatively, if we canpredict a failure a few milliseconds in advance, we may be able to keep the records of operations and2010/12/01

Version 2.0a

Page 15© 2010 Japan Science and Technology Agency

White Paper

DEOS Projectsystem status changes which will be useful for the analysis of the root cause of the failure later, evenif we cannot prevent its occurrence or system shutdown.
The operations and status of the system before a failure could be recorded on a device like a flightrecorder, which keeps record of flight data before an aircraft accident by continuously writing thelatest flight data. However, if the system predicts a failure in advance, the system will have moretime to select the relevant data and to record only that data for a longer period. Therefore, we
consider that methods to predict failures and to detect anomalies are critical for systemdependability. Such methods would involve:z

Detecting anomalies which caused similar failures¾ Infer which anomalies are relevant from patterns of failures in the past

Detecting signs of anomalies¾ Predict anomalies¾ Detect signs which may imply failures in some casesz Rehearsals (to be described in section 3.7)z(2) Restricting/Limiting system resources to prevent failures
We may manage to avoid system crashes or to take some action by postponing an occurrence of asystem crash by restricting system resources when an anomaly which suggests a system crash is
detected.
z

Restrict behavior of a component which shows an anomaly so that the component may notcause a failure

3.5 Responsive Action
Failures are inevitable in open systems environments. Although predictions and rehearsals are
beneficial, they cannot be carried out in all situations. For situations where they cannot be applied,
it is crucial to take some other action to minimize damage after a failure. The action required after
the occurrence of a failure are described below. There are two goals for action after a failure: One is
to maintain or regain the trust of service consumers by minimizing their dissatisfaction andinconvenience, and the other is to maintain the business profits of the service providers.
It is expected the responsive action is taken automatically and autonomically while systems are in
operation. However usually this is not the case, and in most cases the operation of whole systems ora part of the systems are suspended temporarily, stakeholders make some decisions, andmaintainers or operators take some action with human intervention. It is preferable that theperiod of suspended time is minimized. To manage this situation, usually twofold action is planned;
temporary fix or solution, and long term or permanent fix or solution with root cause analysis.
The action thus must:z Minimize the damage and prevent a service shutdown by isolating failures¾ Temporarily halt the failed service, or return the service to a safe operational mode
¾ Maintain services other than the failed service¾ Minimize inconvenience to consumers due to the failed servicez

Quickly uncover the root cause of the failure, repair the failure, and effect recovery of the system¾ Discover the root cause of the failure, and determine the repair which will prevent the same
failure from occurring in the future¾ Minimize the insecurity of service consumers¾ Maintain and even improve mutual trust

Page 16
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

3.6 Cause Analysis
It is always expected to pinpoint the cause of failure, and it is difficult in many cases. Even if thecause of failure is not pinpointed, narrowing down the area of the cause of failure will reduce the cost
and time for the cause analysis significantly, and as a result, it will help to shorten the period ofsystem down time and to find the root cause and long term solution. The technologies required tosupport this need to be investigated and developed. Accurate recording of system behavior orappropriate recording of evidence for cause analysis play a key role.
There has been significant research and development in this area in the past and this is on-going.
The technology in this area is also covered in the DEOS project with a new concept and methodology.
The focus areas in this project are;zzzz

To observe system behavior and keep records (logs)
To investigate and develop the technology to manage large amount of records and to keep only
required log without bankruptcy.
To narrow down the area of the cause of failure in case pinpointing of the cause of failure is
not achievable
To record the behavior of the system just before the system goes into system crash (System
Recorder)3.7 Normal Operations
Keeping records of the systems’ operation and inspecting the records periodically will help tomaintain the dependability of the system. The operators or maintainers may find the symptoms ofsystem failure from this activity. Memory leak may cause significant system failure at some pointof operation. Keeping the system memory at clean status is an effective preventive action.
zz

Keep records of system operation
Prevent system aging

Proactive rehearsal to simulate future systems helps to predict future failure. A failure may
occur when a system reaches a certain state and then runs past a certain date and time. In this case
we can see whether a failure may occur by advancing the system date and time. This is known as arehearsal. The rehearsal will be effective for failure prevention described in section 3.4. Appropriate
rehearsal operations of an actual computer system while the system is in operation are determinedin accordance with the computer system itself and the operation environment. (During thedevelopment phase, similar activities are frequently performed, and they are called “testing.”) If
the system operation is suspended every night, some rehearsals can be done while the system issuspended.
However, if the computer system is available for use 24 hours a day and 365 days a year, somerehearsals can be performed only upon delivery, before it starts service to its customers. If wesubsequently want to perform any rehearsals, we will need a mirror system.

zz

Rehearsals may be performed before the service becomes available to customers (before theinitial release of the system, or before the system starts service each day)
Rehearsals may be performed on a mirror system.

2010/12/01

Version 2.0a

Page 17© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

4 Project Direction
4.1 Project Goal
In this project, “Dependable Operating Systems for Embedded Systems Aiming at Practical
Applications”, the requirements for today’s embedded systems such as reliability, security, andusability, are derived from the concept of “Open Systems Dependability”. A dependable OS for
embedded systems, as well as the concepts, architecture, specifications/implementation guidelines,
management process, framework, development environment and tools and other related platform
technologies necessary for various types of practical implementation are developed. Evaluation
criteria are set, clarified, and standardized. In this project, “OS” is not defined as “operating
system” in the strict sense of the word. “OS” here has a broader meaning, including all system
software layers supporting the system applications. Moreover, the embedded systems we have inmind are defined so as to include systems used as social infrastructure and connected to a network,
such as traffic information control systems and railway ticket systems.
Note that, at present, since systems for monitoring, production control, communication control,
office information equipment, vehicle information equipment, robots, information electronic devices,mobile phones, mobile information terminals, and others can be regarded as applications of the OS
we seek, further narrowing of our range of research according to real users’ needs should beconsidered.

4.2 Project Objectives
The following are the objectives of this project:
1

Establish a clear concept of dependability appropriate for the 21st century.
1.a
1.b

Evaluate and refine the concept of Open Systems Dependability that was discussed in Chapter 2.
Develop elemental technologies, management processes, and system architecture that will
enhance Open Systems Dependability throughout a service and system’s lifecycle.

2

Promote practical applications.

3

In accordance with 1 and 2 above, set an evaluation standard for dependability, and promote its
standardization and clarification (to be suitable as an international standard.)
Start a consortium or user organization for the utilization, maintenance, and enhancement of 1
to 3 above.

4

Create specification and implementation guidelines for a dependable embedded system that is suited
for actual practical uses; develop frameworks, a development environment, and tools; establish amanagement process; and construct a demonstration system for evaluation.

The elemental technologies, processes, management practices, and system architecture required
to build a dependable system will be evaluated and enhanced throughout the development ofpractical systems in a continuous improvement cycle. The deliverables of the project are expected to
be used by industry in the provision of products and services, and subsequently improved throughthe feedback received regarding their practical usage. Furthermore, it will be essential in the future
to establish a society-wide open structure to support the sharing of system failure information, andto carry out social responsibilities such as indemnity and accountability.

4.3 Realizing Open Systems Dependability
There are 3 domains in the implementation structure that need to be integrated in awell-organized way to properly manage Open Systems Dependability: elemental technologies,
management processes, and system architecture [13].

Page 18
2010/12/01

Version 2.0a

DEOS ProjectThis project conceptualizes,
does research for, and develops
a fundamental, well-organizedstructure. We intend to makeour results widely utilizable byembedded system and service
providers (Fig. 11). The
research teams from 9 researchorganizations are working as
one to achieve this objective.

White Paper

System Architecture

The system architecture
should have the following
features in order to integrate
the elemental technologies andthe management processes
effectively:

リファレンスFramework

党
マ
・

党
マ
・

● Preventability システム
マ
V
マ
V
[マ
・ System and フレームワーク
Application Monitoring [マ
±
P
±
P
マ
マ
笠
・ Anomaly andランタイム
Predictive Detection 笠vマvマ・ Security Attack Protection
マ
A
マ
A
ポリシー管理・マ
マ● Manageability
制御機構
Reconfiguration
・ Isolation ／Migration／
エビデンス管理・● Improvability
記録機構
・ Lifecycle Management
カーネル● Accountability
・ Evidence Management and Logging
システム監視・管理機構
・ Policy and D-Case Management

党
マ
・
マ
V
[マ
±
P
マ
笠
vマ
マ
A
マ

Tools
党

マ
・
●V
マ Design tools[マ ・ D -Case Editor±P
マ ・ Policy Scripter
笠vマ●Aマ Verification tools
マ ・ Type Checker
アプリケーション監視・・ Model Checker
管理機構● Test tools
・ DS -Bench
カーネル・ D -Cloud・・・

Hardware● Monitoring and Analyzer
・ Monitor & Logging
・ Incident Analysis
・ Failure Prediction
・ Evidence Registration
・ Cause Analysis

・・・(1) Systems Architecture© 2010 Japan Science and Technology Agency● Constraint and Control
・ Isolation
・ Migration
・ Reconfiguration/Undo
・ Quota・ Security
・ Software Anti -aging

・・・● Verification and Evaluation
・ Benchmarking
・ Metrics
・ Fault Injection

・・・● Record
・ System Recorder・ Record Box

・・・● Management
・ Policy Management
・ D -Case Management

Elemental Technology

・・・● D -Case● Policy● Evidence

Processes● Failure Reacting Cycle● Requirement/Environment
Change Accommodating Phase
Standardizations● Evaluation Criteria● International Standards● Guidelines

Processes & Management

Fig.11. Realizing Open Systems Dependabilityz Schemes for implementing elemental technologies
z Schemes for supporting the management processes (cycle of planning, execution,
monitoring, and analysis)z Schemes supporting system improvement, and enabling changes while the system is inoperation.
To achieve and improve Open Systems Dependability, we need to construct a set of system
software including middleware and various tools used in development phases and operational
phases. In this project, we realize the set of software by the framework and tools described below.

FrameworkD
We call our implementation of the framework “D-fops”, which stands for Dependability
Framework for Open Systems. D-fops is intended to incorporate our research accomplishments
into an integrated software package that companies can use to evaluate the usefulness of theconcept of Open Systems Dependability and of dependability-related technologies in their products
or systems. Research integrated into D-fops includes “monitoring and analyzing”, “virtualization
technologies and their applications” and “security,” which are described later in this document.
If some companies are interested in using the code in an experimental environment, theDependable Embedded Operating System Research and Development Center (DEOS R&D Center)
will provide a system for evaluation of the software together with them. D-fops will be a reference
implementation example, and a user may customize it for use in their commercial products orservices.

Tools

A set of tools called DEOS tools will be developed which incorporates the researchaccomplishments regarding dependability metrics and agreements, policy management, system
software verification, and dependability metrics measurements and evaluation. Although sometools may be used alone, we intend that most of the tools will be effectively utilized together withexisting tools for design, verification, testing, operation, and management. We plan to evaluate
the usefulness of the concept of the Open Systems Dependability and of our framework and toolsin actual development and operation.

2010/12/01

Version 2.0a

Page 19© 2010 Japan Science and Technology Agency

White Paper

DEOS Project(2) Elemental Technologies

Monitoring & Analyzing

Event analysis and verification（incident analysis）

Cause analysis

Normal operation

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

5.3.
5.5.
5.1.

✔

Software aging prevention✔

Security attack protection
throughout network（security）

✔

✔

✔

✔

✔
5.5.
✔
✔

5.4.
5.5.
5.5.

✔

5.5.
✔
5.1.

Testing with time-shift（time-shift
rehearsal）

✔

✔
5.1.

Isolation, reconfiguration andrestoration of failed part
（isolation/reconfiguration/removal）✔
5.1.

Subsystem removal and repair（migration）

Page 20
2010/12/01✔

✔

System resource control and behavior
control（quota）

Verification of virtualization layer

5.3.
5.5.

5.3.

Predictive detection（failure
prediction）
Cause analysis

Related sections

Responsive action

✔

5.3.

Building system containers（isolation）

Resource Allocation & Control

Preventability✔

Achievement of accountability

System monitoring and logging（monitoring & logging）

Design/Implementation/
Verification/Testing

System change requests basedon stakeholders’ agreement

The following table shows elemental technologies which we think at present are mandatory toachieve Open Systems Dependability, and how they contribute to each phase of DEOS processes
described in Section 2.4.

✔

Version 2.0a

Recording

DEOS Project

White Paper✔

Consistent timing system andprotection against fake data（record
box）

✔

✔

✔

✔
5.6.

✔

✔
5.6.

✔

✔
5.2.

Dependability evaluation metrics（metrics）

✔

✔

✔

✔

✔

✔

✔

5.7.

Measurement of system load,
anomalies, and behavior

5.7.

Speeding up a large scale system test
by resource management
Dependability consensus description,
update and management(dependability case management）

✔

✔
5.2.

✔

✔

✔

✔

✔
5.1.

Fail safe mechanism for unknown
failurePolicy script and management

✔
5.1.

✔

Type checking for systems software
Verification & evaluation

5.1.

Recording at the last minute before✔
system goes down（system recorder）

Model checking for systems software

Management© 2010 Japan Science and Technology Agency

✔

✔

✔

✔

✔

✔

✔

5.2.
5.3.

Table 1. Elemental technologies and how they contribute to the four characteristics
Note: The five categories in the leftmost column are for reference purposes. The usage of eachtechnology is not limited to these categories.

(3) Processes & Management
As we discussed in the previous chapter, making open system services continuously available
requires preventing system failure in advance, responding to unexpected failures quickly, andimproving the system appropriately to accommodate changes in the stakeholders’ requirements andthe systems environment. In addition to these, the actions to system failures or the activities forthe system improvement need to be described to stakeholders. As it has been discussed in Chapters
2 and 3, we propose a DEOS Process consisting of a “requirements/environment change
accommodation cycle” and a “failure reacting cycle” to achieve this.
The current V-model and agile software development processes focus on the system development
phase. The DEOS Process is different from these conventional models in that it focuses on theoperation and maintenance cycle. We consider that the system development phase covered inconventional software development processes is a very early, albeit distinctive, part of the operationand maintenance cycle in that it also is carried out incrementally according to changes instakeholders’ requirements and the system environment. Also, reacting to unexpected failuresappropriately is important for open systems. We assumed two cycles based on the above
consideration; both cycles related to each other. It is required to improve the system to provide longterm solutions to react to failures in the “failure reacting cycle”, which leads to the

2010/12/01

Version 2.0a

Page 21

© 2010 Japan Science and Technology Agency

White Paper

DEOS Project“requirements/environment change accommodation cycle”. Besides, improvements to the systemthrough the “requirements/environment change accommodation cycle” become a potential cause of
future failure, which leads to the “failure reacting cycle”. These two cycles move forward
interacting with each other and in parallel throughout the lifecycle of one system. Figure 12 shows
how the elemental technologies developed in the DEOS project are used in the DEOS process.
z Requirements/Environment change accommodating cycle¾ Partial improvements to the system are performed to accommodate change.
Verification of the modified part is done using Type/Model Checker which verifies thesoftware by mathematical methods, and the result is used as evidence of the correctnessof the software.
¾ The system with partial improvements is simulated by the large scale computing andsimulation capability of DS-Bench/D-Cloud, and the result is used as evidence that thepartial improvement does not cause faults.
¾ The improved part of the system is released for use.
z Failure reacting cycle¾ Detection and analysis of failures is performed using D-Logger and D-Analyzer.
¾ Reactive action to the failure is performed using D-Visor and D-Effector.
¾ Reconfiguration of the system to react to the failure is performed.
¾ Log data of the failure is recorded in D-Box as an action of future failure prevention.
Throughout this process,D-Case is used to get toagreement from stakeholders bydescribing the action to thefailure in open systems and theimprovement of the system, as
well as accurate records ofsystem behavior and appropriate
evidence. D-Case documents
are updated whenever a system
is changed with thereconfiguration function or codeenhancements, and may be used
to explain to stakeholders thelatest dependability status of thesystem at any time.
The elementary technologies
mentioned here will be describedin detail in Chapter 5.

D-Logger

D-Analyzer

D-SystemMonitorAnomaly detection
Analysis

D-Effector

D-VisorQuick
Responsiveness

D-Box

D-CaseWalkerD-CaseEditorEvidence
management

D‐CaseExecution

D‐CaseUpdateDEOS Framework＆Tools
DEOS Process

Type/Model
Checker

DS-Bench/
D-Cloud

Evidence by Unit test

Evidence byIntegration test

D-CaseD-Casegrowth cycle
Requirement/Environment
Change accommodating cycle
System change requests
based on stakeholders’agreement
Stakeholders’requirements/
Systemenvironmentchanges

DesignImplementation

Verification

Test

Cause analysis
Responsive action
Failure prevention

Failure reacting cycle
Anomaly detection/
Unexpected failure
happenAchievement ofaccountability
Normaloperation

Fig. 12. Systems Development & Operation using DEOS Technologies

4.4 Project Deliverables
The following are the expected deliverables of this project:
•
•
•
•
•

•

Open systems dependability concept
Elemental technologies（specification for each technology, API reference document, code,
implementation guidelines, etc）
Process（process guidelines, etc）
Framework, development environment and tools (system architecture specifications, API
reference document, code, implementation guidelines, etc）
Metrics, standard guidelines and record format
Open systems dependability consortium

Page 222010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

5 Major Research and Development Status
5.1 Framework

Recording at the last minute before system goes down（system✔
recorder）
Consistent timing system and protection against fake data（record box） ✔
System resource control and behavior control（quota）
Fail safe mechanism for unknown failure
Software aging prevention
Testing with time-shift（time-shift rehearsal）✔
✔

Normal operation

Cause analysis

Responsive action

Preventability

Achievement of accountability

Design/Implementation/
Verification/Testing

System change requests basedon stakeholders’ agreement

Objectives
D-fops, the Dependability Framework for Open Systems, is an integration of the elemental
technologies of the DEOS project (such as 5.2: Dependability Case and Stakeholder Agreement
Processes, 5.3: System monitoring and Evidence Analysis, 5.4: Security and 5.5: Virtualization and
its Application). D-fops implements the following functions:

✔

✔ ✔ ✔
✔ ✔
✔
✔
✔

✔

✔

✔

Isolation, reconfiguration and restoration of failed part
（isolation/reconfiguration/removal）✔

Subsystem removal and repair（migration）✔

✔

Strategies
D-fops is under development to achieve the objectives mentioned above. It is designed to support theDEOS process (shown in 2.4). It consists of a set of system features to sustain the dependability ofservices desired by stakeholders. It is primarily for embedded systems, but is also applicable to othersystems including computer systems for social infrastructure. The functions of each service
component of D-fops are described below.
D-VisorThis provides a mechanism for securely isolating two or more subsystems, each of which is run in
an isolated partition called a System Container. System Containers are independent from eachother, preventing anomaly/failure in one container from affecting the other containers.
D-Application Manager
This provides a mechanism for securely isolating two or more applications, each of which is run in
an isolated named space called an Application Container. In addition, it controls the lifecycle ofeach application program (invoking, revising, and terminating the program) and provides amechanism for a system designer to develop a system which can monitor/analyze the behavior of
application programs and take appropriate action. It also provides a control API that allows
improvements in Open Systems Dependability. An application program which is implemented
carefully to improve dependability using the API is called a D-Aware Application. The
D-Application Manager provides basic monitoring services to other existing application programs,
so-called legacy applications, and enables appropriate action upon these applications to be taken.

2010/12/01

Version 2.0a

Page 23

© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

D-Logger/D-Analyzer/D-Effector
D-Logger monitors the behavior of applications. D-Analyzer analyzes the monitoring results.
D-Effector takes necessary action. D-Analyzer also has functions to select the data which isnecessary as evidence and to compress this data. D-Box and D-Analyzer cooperate with each otherto record evidence.
D-Case Walker
This takes action dictated by system action policies and the agreed-upon definition of
dependability described in D-Case, which will be discussed later in section 5.2, in order to improveOpen Systems Dependability.
D-System Monitor
This independently monitors the system behavior from outside the OS. It also ensures system
integrity by monitoring system failures and attacks from the outside.
D-Box
This records useful information such as D-Case, policy, and evidence useful to improve Open
Systems Dependability. It guards information integrity using access control, encryption, andmanipulation detection.
Deliverables¾ System architecture specification¾ API definition¾ D-Analyzer, D-Case Walker, D-Logger and D-Box program codes, etc¾ Implementation Guideline for Embedded systems, etc

Applications

Middleware

Application
Containers
D-Application Manager

Tools

D-Logger

D-Analyzer

D-SystemMonitor

D-Box

D-Case Walker

OS

D-Effector

OS

SystemContainers

D-Visor● D-Case● Policy● Evidence

Framework

Fig.13．Framework System Configuration

Page 24
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

Normal operation

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

Cause analysis

Preventability

Responsive action

Achievement ofaccountability

Design/Implementation/
Verification/Testing

System change requests
based
on stakeholders’agreement

5.2 Dependability Metrics and Stakeholders’ Agreement Processes✔

Dependability evaluation metrics（metrics）
Dependability consensus description, update and management（dependability case management）
Policy script and policy management

Objectives
The diversity and changeability of open systems make it inherently challenging for stakeholders to
obtain agreements and assurances on the dependability of systems. Furthermore, in an open
environment, stakeholders must maintain the dependability of both the whole system and all
subsystems whose boundaries are ambiguous and dynamic. Meeting these challenges requires
support for the agreement-making process and evidence-based accountability for the correct
implementation of agreements. Also, a mechanism for sharing dependability information throughsystem interfaces is required, for various system relations, e.g., the inclusion relation of anembedded system and embedded OS components and the correspondence relation of servers andclients in network systems.
To satisfy these requirements, first, we need a dependability modeling language for describing thedependability requirements in a form understandable to diverse stakeholders. Second, we need adependability metrics as a base for mutual agreement among stakeholders. Third, a process should
be in place that ensures traceability between the dependability descriptions and actual systembehaviors. The process not only tracks the development phases of a system but also monitors thesystem during operation, constantly checking that dependability requirements are being satisfied.
Furthermore, in open systems, information of dependability requirements must be shared among not
only stakeholders, but also among stakeholders and systems. Therefore, we need to develop atranslation mechanism from dependability requirements written in the modeling language into
codes readable by systems; interfaces for sharing dependability requirement information among
stakeholders and systems.
Thus, we propose the “D-Case method'' with the following goals. As explained later, a D-Case is anassurance case for dependability.
1. D-Case Language, a dependability modeling language to facilitate dependability agreements
and evidence-based accountability and a translation mechanism from D-Case Language into
codes readable by systems
2. Dependability Metrics for open systems to evaluate and ascertain described and achieved
dependability.
3. D-Case Tools for D-Case document creation, consistency checking, verification, presentation
for agreements and accountability, maintenance, and interoperability with existing tools.
4. D-Case Process, system life-cycle processes that define and coordinate D-Case activities / tooluse, at each life-cycle phase, in relation to existing ones.
Strategies
For these goals, we set the following directions.

2010/12/01

Version 2.0a

Page 25

© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

1. D-Case language
We designed the D-Case Language, a dependability modeling language to describe agreements
among stakeholders on dependability and to explain how it is assured based on evidence. We
adopted as a starting point the Goal Structuring Notation (GSN) developed by Tim Kelly and hiscolleagues at the University of York, one of two prominent graphical notations for arguments inassurance cases. Arguments in GSN are structured as trees with a few kinds of nodes, including:``goal'' nodes for claims that arguments are meant to substantiate, ``strategy'' nodes for reasoning
steps that decompose a goal into subgoals, and ``evidence'' nodes for references to direct evidence
that respective goals hold. D-Case Language extends GSN in several ways. For example, we add``monitoring'' nodes to denote operation-phase evidence supplied by monitoring mechanisms as well
as evaluation functions based on dependability metrics. We call a document written in D-Case
Language a D-Case document.
A novelty of D-Case is that in a D-Case document, we argue dependability of systems by precisely
following DEOS process. To achieve Open Systems Dependability, stakeholders must makeagreements on future systems changes, using their knowledge and wisdom to their best effort. To
that end, not only the information of the structure of the target system and the subsystems (i.e., amodel of a relation of the whole system and the subsystems), which is often used in safety cases, but
we also describe how the target system adheres to each phases of the DEOS process. In this way, weneed to establish a methodology for describing both the structure of systems and processes in a
uniform way. D-Case modeling language, as the language for dependability description must be
elaborated to satisfy this requirement.
2. Dependability Metrics
To express differing degrees of dependability requirements for systems with different purposes,
quantitative measures of dependability are necessary. It is also essential for meaningfulnegotiations among stakeholders towards mutual agreements on dependability. So we develop
dependability metrics for the quantitative evaluation of systems dependability.
In the development phase, customers and developers may use the metrics to argue how much of aweighted combination of dependability requirements can be realized at what cost, etc. In theoperation phase, operators coping with failures may be helped by real-time measurements ofdependability in devising recovery strategies etc.
D-Case documents are crucial in considering dependability metrics since it is they that clarify what
to measure and what measured values mean to stakeholders. Weights can be assigned to goals andmeasurements on them can be integrated into a quantitative evaluation depending on how each goalis supported by sub goals and evidence. The live link between D-Cases and systems, explained
below, enables timely evaluation on live systems based on operation-phase evidence.
3. D-Case Tools
The following are being developed: D-Case Editor to edit/verify D-Case documents, D-Case Viewer
to display/monitor dynamically changing live D-Cases for systems at the operation phase, and a
Dependability Metrics Visualization Tool to provide visual, quantitative evaluation functions for
D-Case Editor and Viewer.
4. D-Case Process
We provide D-Case process for dependability agreements and assurance based on evidence. In the
DEOS process, according to system failure and requirements and environment changes, D-Case
documents are updated, and gradually corrected and refined. We call the process for maintaining
D-Case documents as the D-Case process. Also, to facilitate writing D-Case documents, we design
D-Case patterns for each system domain.
A case of using these tools is as follows. At each phase of a system life cycle, D-Case Editor is used
to record as D-Case documents, explain, and verify various negotiations and agreements among
stakeholders on dependability. Agreements are made according to the D-Case Process for thatphase, and, in the process, evaluation scores are given by Dependability Metrics Visualization Tool
to provide an objective basis for negotiation. At the operation phase, the D-Case is relayed to the
D-Case Viewer. Dynamic display/monitoring of D-Case together with runtime evidence and D-fops

Page 26
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

action from systems/environments helps operators/maintainers/users to recover from and improveupon unexpected failures. D-Cases need to change as all systems change during their lifetime due
to changing stakeholder requirements, reconfiguration, etc. D-Case methodology aims to contributeto Open System Dependability by managing/maintaining stakeholder agreements, evidence-based
assurances, and accountability in a synchronized manner with changes in live systems/environments(Fig. 14).

Fig. 14.

D-Case Process

Deliverables¾ D-Case modeling language specification¾ Dependability metrics¾ D-Case Tools：D-Case Editor、D-Case Verifier、D-Case Viewer、and Dependability Metrics
Visualization Tool.
¾ D-Case process
z D-Case Pattern

2010/12/01

Preventability

Responsive action

Cause analysis

Normal operation

System monitoring and logging（monitoring & logging）

✔

✔

✔

✔

✔

✔

Event analysis and verification（incident analysis）

✔

✔

✔

✔

✔

✔

Version 2.0a

Design/Implementation/
Verification/Testing

Achievement of accountability

Monitoring &Analyzing

System change requests basedon stakeholders’ agreement

5.3 System Monitoring and Evidence Analysis

Page 27

© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

Predictive detection（failure
prediction）
Cause analysis

✔

✔

✔

✔

✔

✔

✔

Objectives
Computer systems have always faced a variety of changes. Some of the changes will be the cause of
unexpected failure. We focus primarily on system monitoring and log analysis for tracking changes
occurring in the operation phase. The system monitored changes are recorded and logged to support
a variety of types of dependability management, such as analyzing the logged events for evaluation,
proactive failure prediction, and root cause analysis, which constitutes a main part the foundation ofopen systems dependability.

Fig．15. Conceptual Overview of System Monitoring and Log Analysis
Figure 15 depicts an overview of our concept model. A log is recorded at various levels of systems,
such as communication system, operating system, language runtime, and VMM (Virtual Machine
Monitor). These logs are analyzed and stored as evidence for indicating the actual behavior ofsystems at failure, and for root cause analysis. We have investigated and developed D-Logger andD-Analyzer working on D-fops, and will provide them as online log analysis mechanisms. The
evidence evaluation based on log analysis will be used for the prediction of failures and for root cause
analysis. We will provide a tool for giving a view for D-Analyzers that will be the part of the root
cause analysis for engineers.
Our ultimate goal is to deliver accountability by conducting risk assessments that are based on theevidence for making profiling of a log of the current state of a system, and will support providing
procedures including failure avoidance and executing accountability and daily checking andimprovement and root cause analysis for failures for achieving open system dependability.
We will take a twofold approach for achieving these purposes.
(1) Evidence Management
A variety of logging records come from operating systems, communication nodes and individual
application programs. Each of these records can be evidence for a certain aspect of the whole. The
integration of these logs is needed and would be useful for root cause analysis, failure avoidance,

Page 28
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

executing accountability and quick action for failures. This would help in failure recovery andcontinuous improvement. We address this problem with a newly defined model of evidence
management, and developed for open systems dependability.
(2) Accountable Logging and Analysis
Logging and analysis has been widely used in computer systems. However, usually in those systems,a very small fraction of internal status information is recorded, and this is not necessarily sufficient
for assuring the verification of the correctness of system behavior. Thus, we have developed a newlogging method that is to collecting evidence for accountability.
Strategies
We have addressed the creation of accountability logging, analysis and evidence management withthe following research direction strategies.
(1) Accountable Real-time Operating System.
As the complexity of real-time systems increase, the model-theoretic and predictable design of atheoretical model of real-time tasks for real-time prediction purposes becomes impractical anddifficult. We only model to determine in real-time the correctness of the execution of real-time tasks
that can be inspected based on log analysis of available logged data. This research direction includes
the need to deal with the overhead problem of real-time logging and the implementation issues ofreal-time on the Linux model.
(2) Accountable Programming Language.
We have focused on constructing a function for the automated generation of application logging thatallows us to inspect and evaluate the correctness of programs. The correctness of programs is judged
based on the specifications of goal-oriented software requirements, and this judgment is entered as
an annotation in the source code. Runtime errors are inspected through stack analysis and theanalysis of other internal information. To implement these ideas, we have extended our
implemented scripting language, named Konoha, in terms of both the language grammar and its
scripting engine.
(3) Traceability of Log Analysis Chain D-Analyzer
Anomaly detection is a crucial part of the evidence evaluation process. That is, anomalies refer tounspecified incorrect behavior, whereas some levels of correctness are specified in the accountable
logging commitment. Rather than the anomaly specification, researchers apply modeling techniquesthat enable them to detect anomalies in accordance with changing situations in open systems.
Evidence consists of multiple independently observed events, and the time and place of these events
must be traceable in terms of the time and place of their occurrence to verify, and the validness of thelog analysis. We address the traceability problem by organizing a variety of loggers and an analyzer,
using domain-specific language-based management.
(4) Stream Evidence Engine (SEE)
D-Analyzers are connected with a traceable log analysis engine named the Stream Evidence Engine(SEE) that includes a domain specific language for evidence analysis, and a streaming evidence
analysis engine. D-Analyzer can use the integrated interfaces of streams through SEE. SEE will also
provide the load-balancing mechanism to distribute its load of analyzing, and it sends the results forthe evidence server through their interfaces.
(5) Evidence Viewer Model
The collected logs for use of evidence range from accountability establishment (i.e., root cause
analysis) to policy change (i.e., risk analysis). A unified dependency viewer is needed to improve theusability of observed events as evidence. This research must include the visualization of this unified
model for a human operator and the system integration of automated management into D-fops. In
particular, we will present an online fault analysis viewer that views various aspects of system

2010/12/01

Version 2.0a

Page 29© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

behavior in terms of dependable risk analysis (a FTA extension), and event traceability (root cause
analysis).
Case Study in Robotics
As a case study of a highly advanced embedded system, we are planning to apply our developed
techniques to robots that have been developed at AIST (National Institute of Advanced Industrial
Science and Technology).
Deliverables
Our final deliverables are planned to be as follows:
¾
¾

¾

¾

Multi-OS architecture; supports a real-time logging mechanism for inspecting that verifies thecorrectness of real-time task execution in real time.
Accountable Konoha language, a newly designed dependable scripting language that supports astatic type checker and automated logging for inspection verification of the correctness of
scripted programs.
D-Logger; collects various types of logs from the various layers in the system.
D-Analyzer; provide the various type of analysis for the log, such as a model-based anomaly

detector and proactive performance anomaly detector that support the detection of anomalies fromtheir logs with novel approaches.
¾ Evidence Viewer; evidence management viewer that views various aspects of system behavior¾

in terms of agreed-upon dependability agreements (D-Case), risk analysis (a FTA extension),and event traceability (cause analysis).
Knowledge Data for Robotics failures.

✔

Normal Operation✔

Cause Analysis

Responsive Action

Achievement of Accountability

Failure Prevention

Technology to defend attacks fromnetworked nodes (Security)

Design, Implementation,
Verification, Testing

System Change Requests basedon Stakeholders’ Agreement

5.4 Security✔

Objectives
To improve open system dependability, a security mechanism is mandatory to defend against
various security threats. We provide a secure execution mechanism for operating systems; itguarantees that the security mechanism of the operating system is working correctly. It monitors theruntime behavior of the operating systems and guarantees it is working as it is expected.
The hijacking of operating systems is one of the most serious threats to computer security. This isbecause none of the security mechanisms can be trusted if the operating system, which plays the role

Page 30
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agencyof trusted computing base, is hijacked and functions in an unexpected way. We provide a secure
execution environment for operating systems by defending against attempts to hijack operating
systems.
In open systems, security
mechanisms such as
authentication, authorization,
and access control should evolveas the demands of applications
change. Actually, thesefundamental security
mechanisms are still hot topics
of security research. In thisproject, we allow the use of new
operating systems equippedwith advanced security
mechanisms, and guaranteethat the operating systems areworking in the expected way byrunning them in a secureenvironment.
Strategies
Fig. 16. Monitoring OS behavior using VMM
To implement the above goals,
we use virtual machinetechnologies. More concretely,
we prepare at least two virtual
machines, one for executing a monitored operating system and the other for executing a monitoring
operating system. The monitoring operating system monitors the behavior of the monitored
operating system, checks the validity of the behavior, and raises an alert when the operating systembehavior is deviant. (See Figure 16).
The monitoring operating system can inspect various types of behavior of the monitored operating
system. For example, access to privileged registers, execution of privileged instructions, and I/O
operations can be reliably inspected because the monitored operating system cannot fake thesebehaviors. Furthermore, the underlying VMM can inject hardware/software traps into the system.
Through this trap injection and observation, it can be verified whether the monitored operating
system is functioning as expected (See Figure 16). We also provide the rigorous isolation of virtual
machines that can avoid denial-of-service attacks.
Our design has several advantages over the traditional signature-based detection and prevention of
malware infection. Traditionally, a signature must be developed for each malware sample. In
contrast, for our monitoring system we have only to develop a monitoring module for each class of
malware. For example, to defend against the class of malware that tries to hide the existence ofmalicious files, we simply provide a monitoring module that matches the list of file names obtained
from I/O operations with that obtained from the system call results; one module can detect all
samples belonging to the same class of malware. To deal with a new class of malware, we have todevelop a monitoring module for that class, but the monitoring operating system is carefully
designed to facilitate the development of such modules.
To develop monitoring modules, intimate knowledge about malware is necessary. Modern malware
is quite difficult to analyze because they are tactically ciphered and obfuscated. Even if we use adebugger to analyze malware, the malware stops its execution when it detects the existence of the
debugger. In this project, we have also developed a suite of malware analysis tools; currently, we aredeveloping a behavior analysis tool for malware that makes use of symbolic execution.

2010/12/01

Version 2.0a

Page 31© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

Deliverables¾ D-System Monitor module to monitor OS behavior¾ Virtual Machine Security Architecture¾ Support tool for analyzing malware behavior

Technology to monitor and log
various events that occur in systems(Monitor & Logging)Technology to identify and extractcauses (Cause Analysis)

✔

✔

✔

✔

Technology to realize System
Containers (Isolation)✔

Normal Operation

Cause Analysis

Responsive Action✔

Technology to maintain memory
resources in clean condition(Software Anti-aging)Technology to defend attacks fromnetworked nodes (Security)

Technology to make virtualization
layers reliable (Verification of
Virtualization Layer)

Failure Prevention

Achievement of Accountability

Design, Implementation,
Verification, Testing

System Change Requests basedon Stakeholders’ Agreement

5.5 Virtualization and its Application

✔
✔

✔

✔

✔

✔

✔

✔

Objectives
The D-System Monitor aims to contribute to Open Systems Dependability by employing
virtualization technologies, and D-Visor provides the virtualization technologies that D-System
Monitor requires. D-System Monitor and D-Visor are parts of the D-fops (Framework), and theywork together with the other components that constitute D-fops. D-System Monitor realizes
technologies such as Monitor & Logging, Cause Analysis, and Security, as its elemental technology.
D-Visor also realizes Software Anti-aging and Isolation technologies. D-System Monitor and D-Visor
constitute the basis of the security architecture described in Section 5.4.
Strategies
D-fops (Framework) is based on virtualization technologies, and its functionalities rely on services
constructed on a virtualization layer outside of an OS. D-System Monitor and D-Visor are amonitoring service and a virtualization layer of D-fops, respectively. Their details are described
below.

Page 32
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

The objective of D-System Monitor is to realize Monitor & Logging, Cause Analysis, and Security.
In order to achieve its objective, D-System Monitor continuously monitors the behavior and internal
data structures of an OS from the outside. And then, D-System Monitor analyzes the monitored datain order to guarantee the OS is operating in the expected way.
D-Visor realizes the Isolation
mechanism and implements System
Containers in order to enable
D-System Monitor to safely monitor an
OS from the outside. By executing an
OS in a System Container realized by
the Isolation mechanism of D-Visor,
the execution environment of
D-System Monitor can be clearly
separated from the environment of themonitored OS (see Fig. 17).
D-System Monitor guarantees themonitored OS is operating in the
expected way by analyzing its runtime
Fig 17. Dependability Support by D-System Monitor
information provided by D-Visor.
on an isolated environment realized by D-Visor
D-Visor provides the runtime
information, such as access to privileged registers, execution of privileged instructions, and I/Oprocessing and data, for the D-System Monitor. Moreover, D-Visor can monitor the reactions of themonitored OS to more specific events by injecting external interrupts and software interrupts thatinvoke system calls. From the monitored behavior, D-System Monitor can determine whether themonitored OS behaves as expected. D-Visor also provides Software Anti-aging mechanism thatquickly and simply recovers data integrity in a monitored OS.
D-Visor should not cause failures since it is introduced into the system in order to achieve
Sustainability, which is the essential objective of Open Systems Dependability. Thus, D-Visor cannot
be compromised either since it is the base of the system that enables the monitoring of an OS fromthe outside of it. Therefore, the implementation of D-Visor is verified by the model checker, which is
being researched and developed by this project. The verification effort of D-Visor aims to provide a
specification description to avoid fatal errors that lead to the service outage of System Containers.
It is very difficult that a single implementation of D-Visor fulfills all the requirements for every kindof embedded systems. Since embedded systems are used for a wide variety of purposes in a numberof ways, their utilization environments differ substantially. Low power consumption can be a very
high priority requirement for some systems while real-timeliness can be the highest priority
requirement for some other systems. There are also many kinds and configurations of embedded
processors used in target systems. Therefore, it is better to provide different implementations of
D-Visor that match the needs of target embedded systems. While D-System Monitor utilizes System
Containers, it requires different functions for System Containers depending upon the functionalities
it realizes. Thus, a metric is being developed to help users construct systems that best fit their needs.
Deliverables¾ D-System Monitor modulesz Software module to monitor OS internal data structuresz Software module to monitor OS behavior¾ D-System Monitor runtime API¾ D-Visor for embedded systems¾ D-Visor for hard real-time systems¾ Verification specification description for D-Visor

2010/12/01

Version 2.0a

Page 33

© 2010 Japan Science and Technology Agency

White Paper

DEOS ProjectTechnology for Model Checking ofSystems Software✔

✔

Technology for Type Checking ofSystems Software✔

✔

Normal Operation

Cause Analysis

Responsive Action

Failure Prevention

Achievement of Accountability

Design, Implementation,
Verification, Testing

System Change Requests basedon Stakeholders’ Agreement

5.6 Systems Software Verification

Objectives
When features are added or modified in existing systems, new bugs must not be introduced. One ofthe objectives of this project is to develop formal program development approaches and tools for
detecting defects in systems software including operating system kernels, thereby contributing to
the achievement of Open Systems Dependability, especially for the “Design, Implementation,
Verification, and Testing” phase of the DEOS process. In addition, the approaches and tools support
the “Fault Prevention” phase in the sense that the tools can detect bugs in programs before executing
them.
Strategies
In order to achieve the objectives mentioned above, this project has been researching and developing
two formal methods, model checking and type checking, for the formal verification of C programs
which are frequently used for systems software (Figure 18 and Figure 19) in the “Design,
Implementation, Verification, and Testing” phase. In the DEOS process, verification tools are used
not only in the development phase of a software system, but also in the maintenance phase where asystem continuously evolves in order to improve Open Systems Dependability.
From the viewpoint of achieving Open Systems Dependability, both of the methods have drawbacks
and advantages. Model checking can verify relatively complex safety properties. However, this takes
a long time. On the other hand, type checking can be done in a short amount of time. However it canverify relatively simple safety properties. To address this problem, we combine the two methods in acomplementary manner.
Model checking is a method of reading C programs, exploring all execution paths, and checking
whether developer-specified properties (conditions) are satisfied or not. These properties are written
in a specification language as conditions on the variables of the programs. Because the properties
can be modified or added, measures to prevent a certain Open Systems Failure, which is caused bychanges in the external environment or in user demands, can be subjected to model checking byadding conditions of failure to the properties to be checked.

Page 34
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

While properties checked by model checking can be written by programmers, it is unclear what
properties should be written and how. To make it clear, we provide a specification description toextend the Linux kernel safely by defining the constraints on functions and variables.
Type checking is a method for checking and ensuring that a program never performs illegal
operations. For example, it ensures that the program never accesses outside of arrays or jumps toillegal addresses. First, programs written in C are compiled into a Typed Assembly Language (TAL),
which is a type-safe assembly language with the type information of programs. During thiscompilation, runtime checking codes are inserted where type-safety properties cannot be guaranteed
statically. Then the generated TAL codes are assembled into binary executable forms, which also
have the type information. Thus the type-safety properties of the generated binary executable forms
can also be checked. This makes it possible to ensure the simple safety properties of programs
continuously even when a system needs to be modified because of changes in external environment
or user demands.
Deliverables¾ Model checker for systems software written in C
¾ Specification description language for systems software¾ Specification descriptions for Linux kernel extensions¾ Typed Assembly Language (TAL) for systems software and type checker¾ Type-safe compiler from C to TAL

Fig. 18.

2010/12/01

Version 2.0a

Page 35

© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

Fig. 19.

✔
✔

✔

Normal Operation✔

Cause Analysis✔

Responsive Action

Failure Prevention

Observation of Load, Anomaly
Condition, and Behavior
Acceleration of the System Test by
Managing Massive Computing
Resources

Achievement of
Accountability

System Change Requests
based on Stakeholders’AtDesign, Implementation,
Verification, Testing

5.7 Dependability Measurement Tools and Test Tools✔
✔

✔

Objectives
In the D-Case process, anticipated anomaly conditions are enumerated, and evidence is needed toshow whether the system requirements are satisfied under each anomaly condition. The limit of thesystem against these anomaly conditions must be calculated beforehand by necessary quantitative
measurements. In addition, in the case of system updates, it must be verified that no problems arise
with a system operation test. The cause of anomalies observed in actual operation must be analyzed
in order to ensure accountability to stakeholders. One of the objectives of this project is to develop
tools for measuring dependability and for rapid system testing, which will contribute to achieving
Open Systems Dependability.

Page 36
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

Anomalies include hardware faults, software bugs, overload, and human error. A common evaluation
environment in which various anomaly loads can be evaluated must be implemented systematically.
In order to observe anomaly conditions or evaluate system operation, a tremendous number ofsystem tests must be carried out. This can only be done by automating the test process andmanaging computing resources appropriately. Complex testing using many test patterns must be
accelerated.
Strategies
The DBench project was an approach to evaluate the dependability of the system carried out fromthe late 1990s to the early 2000s. The dependability benchmark framework, which is a conceptual
framework, was developed in the DBench project. In this framework, the benchmark environment
consisted of a Benchmark Target, Workload, Faultload, and Measurement. In the DBench project, aseparate benchmark environment for each specific application domain was implemented based on
the defined framework.
On the contrary, in our project, DS-Bench/D-Cloud have been designed and implemented to provide adependability evaluation environment with adaptability and extensibility. DS-Bench/D-Cloud can becommonly used for various application areas. Our project partially shares the goals of the DBench
project. However, we aim for the benchmarks to be reused, unlike DBench, and we also aim to makea database of benchmark programs and to make scripts specifying how to execute the benchmarking
based on a fault scenario.
Anomaly behavior caused by software problems, such as software bugs and overload, and hardware
malfunctions that can be caused by controlling hardware devices, such as network disconnection andpower shutdown, are simulated using real machines. If the specifications of a device are written in
the SpecC system description language, hardware faults can be simulated by the combination of the
SpecC simulator and Virtual Machine Monitor on D-Cloud.
Based on the framework of DS-Bench, the fault scenario that describes when to generate faults atwhat workloads, and with which measurement tools is described in XML. This fault scenario isreflected in the scenario for setup and execution of the D-Cloud testing environment, which is also
described in XML, and it is executed in virtual machines and real machines.
The results of the execution based on a fault scenario are also generated in XML format, and arestored in a database. This database provides evidence of how the system responds to overload or
faults.
Deliverables
Figure 17 schematically illustrates the DS-Bench and D-Cloud we aim to create. Their overall
features are as follows.
¾ DS-Bench/D-Cloud Front end：
This provides a Web user interface for users to configure the fault scenario.
Through this interface, many types of software dealing with Anomaly Loads, Performance
Benchmarks, Monitoring Tools, and Anomaly Scripts are entered in the database. Users can use
this interface to configure the dependability benchmark environment. Our project will provide
the deliverables shown below. In addition, users can flexibly append a group of software asnecessary.
z Anomaly Loads：Anomaly Loads are classified into two types: fault emulators for software,and fault emulators for hardware. The fault emulators for software consist of programs that
artificially generate overloads of the CPU, disk I/O, network traffic, and heavy memory
usage. The fault emulators for hardware control the commodity PDU (power strip) toemulate power shutdown faults and the network switch to emulate network disconnection
faults. To deal with faults in memory flip and I/O devices, etc., an environment with thesecan be simulated on Virtual Machines. I/O devices that are not used in general-purpose
computers must be described in the SpecC system description language.

2010/12/01

Version 2.0a

Page 37

© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

Performance Benchmarks：These are programs that evaluate whether the required
performance is sustained under anomaly loads. Benchmark programs that are used
to evaluate commonly used products are available.
z Monitoring Tools：These are tools to monitor the states of the computer.
z Anomaly Scripts：These are fault scenario databases defined by users, and some examples
may be provided.
D-Cloud and Fault-VM：
The environment for executing the dependability benchmark is provided by D-Cloud andFault-VM. Benchmarks that are executable with Virtual Machine and benchmark environment
without special hardware are performed in the cloud computing environment offered by cloud
management software (currently, Eucalyptus), including I/O device models described in the
SpecC language. If the target system consists of real machines or requires a special environment,
the real environment is directly used. D-Cloud assigns the programs based on Anomaly Scripts
to specific Virtual Machines or real machines.
z¾Tester

Frontend
Benchmark Database
ToolMeasurement
Tool
Benchmark
Results

D-Cloud Controller

Anomaly
Generator

Benchmark
Performance
BenchmarkAnomaly
ScriptD-Cloud
Eucalyptus
Cloud Environment
Controller for VM/QEMU
Nodes

Target Hardware
Specific Environment
Controller for Target
Specific Environment
Network Switch

Target Machines(Network Port iscontrolled via SNMP）

VM/QEMU Nodes
Booting Guest OS
Fault Injection

PDU（Power is controlled
via HTTP,SNMP）

Fig.20. Image of DS-Bench/ D-Cloud as a goal

5.8 Process and International Standards
Objectives
Our goal is to develop a dependability standard for information systems that provides objective
criteria with which developers can argue for, and users can be convinced of, the dependability of asystem. We also establish a certification scheme based on these criteria, assessing a system's
conformity to the standard. The certification of DEOS will make its value clear, and will itself be atangible added value of the whole system. We intend the standard to be internationally recognized.
We plan to set up study groups within the international standards bodies in which we participate, toPage 38
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

promote international collaboration in this area, and to submit a standard proposal together withinternational partners.
Strategies
The research and development being conducted has the following focuses:
1.
2.
3.
4.

Formation of the “User Oriented Dependability” concept
Drafting dependability standards
Establishing an evaluation methodology
Establishing lifecycle technology

Item 1 clarifies the concepts of indeterminacy and diversity that have become issues in Open
System Dependability, and explores solutions to the challenge of developing "measures against
unexpected failures," seemingly a contradiction in terms. Item 2 formulates the qualities requiredof dependable information systems, based on the open system dependability concepts clarified in
Item 1. Item 3 provides methods to evaluate a system's conformity to the standard. Item 4gives guidelines on how to design a system lifecycle for continuing conformity to the standard.
Details of activities and progress with regard to each research focus are as follows.
Related existing Standards
IEC 603000s, 61713
ISO/IEC 15288, 12207
ISO/IEC 15026:1998
IEC 61508 etc.

12Requirements elicitation/ analysis / specification

Drafting Dependability Standards
Open System ⇒ International Standards

Evaluation Standards for Open System Dependability
Defining Dependability Levels
Systems are emergent;change like organisms

Formation of“User Oriented Dependability”
Concept

Standardisation activities
ISO/IEC JTC1/SC7/WG7IEC TC56/WG4
OIML
OMG

Risk Management
Risk Communication

Stakeholders share responsibility;
No unlimited liability borne by developers

4

Establishing Life Cycle Technology

3

Establishing Evaluation Methodology

Provision of guidelines for evaluating
conformity to the standard
at each phase of a system life cycle

Provision of guidelines for developers,
operators, and maintainers on their tasks ateach life cycle phase

D-Case tools for construction andverification of assurance cases

Use case 2

Use case 1
D-Case tools support
conformity managementby making specifications

Formal verification etc. isan advisable option.

MaintenanceOperation

Deployment

Testing

Implementation

DesignRequirements
definition

MaintenanceOperation

Deployment

Testing

Implementation

DesignRequirements
definition

Life cycle technology guidelines

Real-time monitoring and verification that performance, operational
policy, etc. are as planned in the pre-operational agreement among
stakeholders.

Life cycle technology guidelines
Producing evidences that maintenance is carried out
in accordance with the agreed policies

Conformity assessment w.r.t. the standard and guidelines

Fig. 21. International Standard and Process Development Approach
Formation of “User Oriented Dependability” concept
Through reviews of existing dependability concepts, discussions among Open System
Dependability groups, and external feedback to the results of the above, we came to identify crisis

2010/12/01

Version 2.0a

Page 39

© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

management for information systems as a key concept in addition to risk management. Since
conventional risk management starts by enumerating risks, it may only counter risks perceived inadvance. The achievement of Open System Dependability, on the other hand, starts byrecognising the necessity to cope with unexpected failures, which is more akin to crisis
management in society at large. The means of crisis management include emergency procedures,accountability, and recurrence prevention.
Drafting dependability standards
We are active in the working groups of international standards bodies such as ISO/IEC
JTC1/SC7/WG7 (Software and system engineering - Lifecycle management) and IEC TC56/WG4(Dependability - System aspects of dependability) as members, editors, or experts, cultivating
collaborations to form the world community for the formation of new dependability standard
proposals. In particular, since 2009, we have been acting as co-editors of the draft international
standards ISO/IEC 15026 for assurance cases.
Establishing evaluation methodology
Agreement among diverse stakeholders in a system will become an ever more important issue forcrisis management and risk management. It is necessary to have systematic support forreaching complex agreements, for checking correctness of agreement procedures, etc. A tool toconstruct D-case documents and verify their consistency is being developed.
Establishing lifecycle technology
For Open System Dependability, it is important for agreement among stakeholders to beappropriately maintained throughout system lifecycles.
The D-Case management process toattain this is being developed.
Deliverables¾ Publication of concept definitions: establishing Open System Dependability concepts.
¾ ISO/IEC international standards: draft standards for Open System Dependability, starting
the process towards formal approval by ISO/IEC.
¾ OMG industry standards: proposals for D-Case standards with industry-wide
interoperability made at OMG meetings.

5.9 Research and Development Activity Results
Each of our teams has madecontributions, including
software for the frameworkand documents which describe
processes, standards,
guidelines, etc. Fig.22 is a mapof these contributions.
DEOS tools produced by thisproject must work withexisting tools. Softwaredeveloped by this project isjust for reference, and it must
be remade to be of practicaluse to the products andservices of each user. The
DEOS development center will
work with users to fit thesystem to user environments.

Page 40
2010/12/01

D-CaseEditor/Viewer

Applications

Open FTA
ViewerMiddleware

Application
Containers

Type
Checker

D-Application Manager

Model
Checker

D-Logger

D-Analyzer

D-SystemMonitor

D-Box

D-Case Walker

D-Effector

DS-Bench
D-Cloud

Tools

D-VisorMonitor& Analyzer

SystemMonitor& Security

OS

OS

SystemContainers

ART-Linux● D-Case● Policy● Evidence

D-CaseVirtualization＆Multi-OS

Framework

Fig. 22. R&D Deliverables and Framework

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

6 Research and Development Organization
This project formed five research teams in 2006 and added four new teams in 2008. They willcontinue research and development until March 2012 and March 2014, respectively. At the
Dependable Embedded OS Research and Development Center (DEOS R&D Center), the deliverablesof the research teams will be integrated for practical use, reconfigured in consideration of
intellectual property and maintenance issues, tested, assessed, and packaged in collaboration withthe businesses that will use them in actual products (Fig. 23).
Althoughthere
arecurrently
nine
teams
participating in this project,their research in theirassigned topics alone may not
be enough to achieve our
mission. For instance, filesystemdependability
isdeemed important, but it is
not currently being studied.

Research Supervisor

Area Management Adviser

Deputy Research Supervisor

Area Adviser
Research Promotion Board

Consortium

DEOS R&D Centerz System Architecturez Frameworkz Reference Systemz Management Processz Development Environmentz Demonstration Systemz Maintenancez Public Relationsz Information
Exchangez Publication& Advertisementz Results
Dissemination

Research TeamFY 2006 Research Teamz Elemental Technologies

Core Team

Sub-core Teams
From here on, through theproposals of the system
FY 2008 Research Teamarchitecture, the design (basicz Elemental Technologies
and detailed) of the referencez Standards/Guidelines, Int’l Standardization
system, and the process ofCommunity
identifying
therequiredExternal
Development
elemental technologies, it will
Resources
become clearer whether open
source software can be
Fig.23. Research and Development Organization (As of October 2010)
utilized as is or not; or,whether it is necessary to
conduct further research and development activities in this project.

To move this project forward, a Research Promotion Board was established which includes
members from private industry to represent the viewpoint of system or service providers. The
board members and the system and service providers will constantly verify the OS requirements,
determine the requirements for its practical implementation and identify problems related to its
practical application. The progress of the project will be disclosed to the public, opinions from people
outside the team will be invited, and feedback that can be applied to the whole project will begathered. This will be done to make the concept of dependability and the methods of developing
and maintaining dependable systems into common public property. The present age of borderlesscomputer systems and businesses brought on by the Internet and economic globalization calls for theconcepts and techniques of this project to be shared with the international community.
On April 1st 2010, we regrouped the core team, whose members are from each research group,
into 5 sub-core teams as given below. Each sub-core team researches an area more deeply, to enable
practical use. Most of the results of the sub-core teams and research teams are to be integrated
within the framework (D-fops) or built into tools. We provide the deliverables needed for system orservice providers to realize dependable systems and services.

2010/12/01

Version 2.0a

Page 41© 2010 Japan Science and Technology Agency

White Paper

DEOS Projectz D-Case & Metrics team:Research and development,
Process, Standards
Framework
Tools
consensus-building for
Guidelines
dependability metrics and their
System monitoring & Evidence analysis
Process & International Standard(EBI team)required tools.
(Kinoshita team)z EBI team:
System software Verification
Security
Research and development of（Systems Software(Kono team)Verification team)system monitoring, analysis andprofiling and required tools.
Dependability Measure & Evaluation
Virtualization & its applicationz VM & Multi-OS team:（VM & Multi-OS team)（DS-Bench/D-Cloud team)Research and development of
virtualization, its application,
Dependability Metrics & Consensus-building（D-Case & Metrics teamand required tools.
z Systems software verification
team:
Fig.24．Role of each Sub-core teamResearch and development ofsystem software verification andits required tools.
z DS-Bench & D-Cloud team:Research and development of dependability measurement and evaluation, andrequired tools.
Also, the following teams collaborate with sub-core teams to realize Open Systems

Dependability. (Fig. 24)

z Kono team: Research and development of security and required tools.
z Kinoshita team: Research and development of processes and international standards for
dependability

7 Roadmap
The completion of the following phases devoted to the items described earlier are the principal
milestones of the entire project (Fig.25).

Fig.25. Roadmap (As of October 2010)

Page 42
2010/12/01

Version 2.0a

DEOS Project
z

z

z

z

White Paper© 2010 Japan Science and Technology Agency

Phase 1 (2006/10-2009/9): Establishment of the dependability concept; presentation of systems
architecture containing major evaluation indexes and development/operation processes
supporting said concept; and demonstration of the 2006 research team’s demo system in which
a number of elemental technologies have been integrated. (Presentation completed 2009/9 by
the 2006 research team.)Phase 2 (2009/10-2011/9): Implementation of a system architecture, framework, and reference
system which adopts the elemental technologies of the research team; establishment of aconsortium (or user organization) composed of actual potential users including those fromprivate industry; formation of an open community for the research and development ofelemental technologies and system architecture; standardization of required items; trial usageof the framework and reference system by consortium members and the gathering of
feedback thereof; demonstration of the research teams’ frameworks and reference systems inwhich some of the elemental technologies have been integrated. (The above will be presented
in September 2011 by the 2008 research team as their interim public presentation.)
Phase 3 (2011/10-2014/3): Trial usage of the framework and reference system by consortium
members; continuing evaluation and feedback; transition to actual development andcommercialization; standardization of the required items.
Phase 4 (20014/4- ): Functional enhancements; and continuing utilization, maintenance anddevelopment by the consortium.

8 Further Issues for Practical Application
8.1 Handling of Intellectual Property Rights and Copyright
The research and development deliverables of this project will be provided to as many system andservice providers and users as possible for their practical use. The deliverables will be provided in
the form of OSS (Open Source Software) as much as possible, in order to contribute to thedevelopment of a social infrastructure using dependable embedded systems. There are various kindsof OSS licensing, such as GNU GPL (GNU General Public License), GNU LGPL (Lesser General
Public License), New BSD License, and MPL (Mozilla Public License). The selection of license typewill depend on what is considered to be the best way to spread the use of the deliverables of thisproject.
The intellectual property rights, including copyright, of each deliverable primarily belong to theresearch organization that produced it. The intellectual properties should be licensed so as to best
spread the use of the project’s future deliverables, and a policy will be decided accordingly.
Intellectual property will be transferred to a specific organization if required and if there is support
from each research organization concerned. The final objective is to provide an IP “one-stop shop”
for the user through one organization such as the DEOS Consortium. Collaboration with external
research and development groups as well as standards organizations will be encouraged, in order toprovide user-friendly deliverables. (The specifics of such collaboration will be considered as a futureissue.)

8.2 Open Systems Dependability Consortium
To put the deliverables of this project to practical use, it is required that their prototypes be triedout by system and service providers for evaluation, that they go through a large scale evaluation
process, that the evaluation results are used to improve them for practical use, and that the numberof their supporters for practical use be increased. The establishment of a consortium of system andservice providers who are potential users, businesses that are potential providers of the deliverables,and related research organizations will help the deliverables of this project to continue being used
after their evaluation. This consortium may well take the role of international leadership in
dependability technology, attracting supporters and users of the deliverables and technologies, and2010/12/01

Version 2.0a

Page 43© 2010 Japan Science and Technology Agency

White Paper

DEOS Projectcontributing to standardization, the development of new technologies, maintenance, education,
certification, etc. The DEOS Center will strive to establish this consortium before projectcompletion, working with potential users and research organizations. Future issues whoseclarification is needed to achieve these objectives are the method of cooperation with potential users
and research organizations, as well as the role, formation, and funding of the consortium. For
potential users and research organizations to agree to join the consortium, they must understandhow critical Open Systems Dependability is, and each system or service provider must realize that
Open Systems Dependability must be tackled throughout each concerned industry and as across-industry matter. Though the required conditions or the roles of the consortium are understudy with market research, current issues for the objectives or business of the consortium aresummarized below.
1.

2.

3.

4.

Understanding the importance of Open Systems Dependability and influencing public opinion
When system failure occurs, the system or service provider necessarily takes action, andthe users and the service provider will be satisfied to some extent if that action is what was
expected by the users or community. The uncertainty of users and society at large regarding
the cause of the failure is relieved if they see evidence of what has happened presented
according to a standard format and procedure.
The report “Towards the Realization of Safe and Reliable IT Infrastructure in Information
Society” issued by the Information Science Committee of the Science Council of Japan in 2008[28], proposed the “establishment of a fact-finding commission for accidents involving
vulnerability of information systems”, that would make proposals about law and education
systems. Collaboration with this kind of organization should be considered.
Establishment of industry-wide or society-approved standard procedures or international
standardization
The procedures for handling system failure and describing it to users or to the public, thecontent to be described and required evidence of causes are to be defined and standardized.
This will clarify accountability and provide a standard throughout the community.
Certification of standard compliance
There may be a need to certify that the products or processes comply with the establishedstandards. There is a potential business here, in which a third party agency does thecertification with support from the consortium.
Development and maintenance of the deliverables by the development community
The development of the framework and elemental technologies required to support Open
Systems Dependability cannot by fully carried out by the members of the DEOS project.
Maintenance and continuous development will be required after the DEOS project iscompleted. Some of those activities may be carried out by the consortium, but it is important
to utilize overseas resources, to establish an international community for DOES, and to get
overseas world-class researchers and engineers to join in these activities. We hope for aworld-wide discussion of the Open Systems Dependability concept, the improvement ofarchitecture, application of the process to the real world, and research and development torealize and improve Open Systems Dependability.

9 References
1.
2.
3.
4.

H. Yasuura, “On Dependability”, T. Nanya, “Concept and Issues on Dependability”, K. Iwano,“Dependability in Social Services”, in Dependability Workshop Report (in Japanese),
CRDS-FY2006-WR-07, CRDS, JST, March 2007
http://www.dependability.org/wg10.4/
A. Avizienis, J.-C. Laprie, B. Randell, C. E. Landwehr,” Basic Concepts and Taxonomy of Dependable
and Secure Computing, IEEE Trans. On Dependable and Secure Computing, Vol.1, No. 1,
Jan.-March 2004
T. Kikuno, “Requirements for Dependability in the 21th Century,” Speech at the Kickoff Symposiumof JST/CREST Dependable Embedded OS Project, December 2006

Page 44
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

5.

M. Tokoro, “On Designing Dependable Operating Systems for Social Infrastructures,” Keynote
Speech at MPSoC, Awaji Island, Japan, June 25, 2007.
6. H. Yasuura, ”Dependable Computing for Social Systems”, Journal of IEICE、Vol.90, No.5, pages
399-405, May 2007
7. T. Kano & Y. Kikuchi, ”Dependable IT/Network”, NEC Technology, Vol.59, No.3, 2006, pages 6-10
8. M. Y. Hsiao, W. C. Carter, J. W. Thomas, and W. R. Stringfellow, “Reliability, Availability, andServiceability of IBM Computer Systems: A Quarter Century of Progress”, IBM J. Res. Develop., Vol.
25, No. 5, 1981, pages 453-465
9. A. G. Ganek and T. A. Corbi, “The dawning of the autonomic computing era”, IBM Systems Journal,
Vol. 42, No. 1, 2003, pages 5-18
10. “An architectural blueprint for autonomic computing, 4th edition”, IBM Autonomic Computing
White Paper, June 2006
11. http://www-03.ibm.com/autonomic/
12. Mario Tokoro, ”Research and Development at Technology Maturity Stage”, Journal of IEICE, Vol.90,
No.9, 2007, pages 742-744
13. Mario Tokoro and others, “Open System Science”, NTT Publishing Co., Ltd
14. H. B. Diab, A. Y. Zomaya, “Dependable Computing Systems”, Wiley-Interscience
15. G. M. Koob, C. G. Lau, “Foundations of Dependable Computing”, Kluwer Academic Publishers
16. M. C. Huebscher, J. A. McCann, “A survey of Autonomic Computing”, ACM Computing Surveys, Vol.
40, No.3, Article 7, August 2008, pages 7:1-7:28
17. K. Matsuda, Foreword, IPA SEC journal No.16， Volume 5, No. 1(Volume 16), 2009, page 1
18. T. Forbath, interview ”Japanese Company should break-away from the 20th century Development
Process ” NIKKEI ELECTRONICS 2009.2.23, page 29
19. A. Avizienis, ” Design of fault-tolerant computers”, In Proc. 1967 Fall Joint Computer Conf., AFIPS
Conf. Proc.Vol.31, pages 733-743, 1967
20. Nassim Nicholas Taleb、The Black Swan: The Impact of the Highly Improbable, Random

House.
21. Leveson, Nancy G., Safeware: System Safety and Computers, Pearson Education.
22. Failure Chains: Warning of the Prius Recall, Nikkei BP press(in Japanese)
23. Owada Naotaka and others, Why Systems Go Down. Nikkei BP press (in Japanese)
24. H. B. Diab, A. Y. Zomaya, “Dependable Computing Systems”, Wiley-Interscience
25. G. M. Koob, C. G. Lau, “Foundations of Dependable Computing”, Kluwer Academic Publishers
26. K.Kanoun, L.Spainhower, “Dependability Benchmarking for Computer Systems”, IEEE
Computer Society
27. B.Kirwan,"A Guide to Practical Human Reliability Assessment”, CRC Press
Science Council of Japan, Board of Informatics, Sectional committee of Security and
Dependability, “Toward the popularization of IT infrastructure realizing Safety and Security”,(Chair: Hideki Imai), 2008/6/26. (http://www.scj.go.jp/ja/info/kohyo/pdf/kohyo-20-t58-4.pdf）
28. Dependable Operating Systems for Embedded Systems Aiming at Practical Applications
Research Area (DEOS Project) White Paper Version1.0, DEOS-FY2010-WP-01, JST, Sep. 1,
2009

10 Appendix
10.1 Dependability Obstructions
If we try to focus on a software’s working environment as a dependability obstruction, its faults
can be divided into four categories: faults from the environment during both operation anddevelopment, faults that are hardware-related, faults brought about by human error, and faults
caused by a random attack. Each fault category can be fully understood by considering thedependability obstructions that type of fault causes in each lifecycle from the time of inception until
termination. A summary is shown in the table below (Table 2).

2010/12/01

Version 2.0a

Page 45© 2010 Japan Science and Technology Agency

Environment (Operating Environment, Development Environment, etc.)
Specification

DesignImplementation and Unit testing

Integration, Test

Distribution / Transportation

Operation

Maintenance, Update

Disposal, Reusechanges in the environment [natural environment, system environment(hardware, software), user environment (organization, operating
environment), reuse of existing applications, frequent changes inrequirement]

White Paper

Hardwareerrors in hardware resource estimation,lack of consideration for software productivity

DEOS Project

Human Error
errors in specification estimation, performance simulation (inaccurateload), noncompliance to standards

Security Issue / Risks
theft of plans/specifications, sending of erroneous/malicious informationfrom outside

wrong tolerance design (for natural environment, system environment
insufficient implementation of test functions,errors in architecture selection/design, errors in interface design
theft of design informationand operating environment), lack of consideration for target operator
lack of consideration for software performance (inadequate software and between modules/subsystems,(end-user, administrator, etc.), bugs in design tool, errors in analysis of hardware partitioning),
omissions in design review, misinterpretation of specifications, errors insystem interdependency, trouble arising from reusing existing programs, specification mismatch between parts
hardware performance estimation, errors in user interface design, wrong
errors in design tool selection, frequent changes in specification
handling of exceptions, mismatch in software versions, insufficientdesign in fault recovery

bugs in development tool, insufficiencies in development environment, schedule delay/miss in the development of target embedded hardware,bugs in development environment (version mismatch, etc), inadequate poor yield/quality, specification mismatch bugs (that can be fixed within
training program, insufficient verification (failure and performance) of the the term/cannot be fixed within the term)
software to be used, frequent changes in design

errors in coding, omissions in code review, errors in algorithm,
errors in library selection, integration
version mismatch, errors in timing assumption,
escapes in unit tests, piracy, patent infringement

illegal production fraud, theft of source code,
patent litigation, copyright lawsuit, embedding of malicious codebugs in test tool/test environment, insufficient test period, frequentchanges in implementation

insufficient testing on the hardware functions, left over hardware bugs

insufficient test items (test cases, operation),
errors in test result verification, errors in test items,
errors in test reviews or test environment configuration

mixing of inferior parts, altering of test results,
theft of test specification/results, intentional omissionschanges in the environment (natural environment,
distribution systems, people in charge, distribution rules）

changes in environmental factors (temperature, shock and tilt duringtransport, submersion in water, other damages）

mixing of defective and counterfeit parts, occurrence of accidents during mixing of counterfeit and stolen parts, damage, tamperingtransport

aging (changes over time), environment temperature,environment humidity, errors related to other systems' failures,
system downtime due to unexpected data, input overload,
shock/impact, power failures (power flicker, fluctuations,
blackout, unplugging of electrical outlet), noise (electromagnetic ray,static electricity, cosmic ray), frequent version updates/patches,
excessive operation cost, service termination or malfunction due toremaining bugs

deterioration of hardware (mechanical, chemical, physical), poor contact misunderstandings of specification, user error due to poor user interface infiltration during operation (spyware, virus, attack),(connection, switch), excessive power consumption, noise,
design, incorrect operation (incorrect function selection, incorrect dataattaching of illegal modules, extraction of data, intrusion,
electromagnetic noise, heat
entry or selection), errors in installation, errors in configuration, errors in information leakage
data transfer

irreproducible bugs/errors, bugs in maintenance/update tool ,frequent (excessive) version updates,lack of version update history data, excessive maintenance costlack of features for collecting malfunction information,
Inappropriate maintenance period of parts,
incompatibility of new partsinsufficient notice of a malfunction,
infiltration during maintenance/update (virus, attack),
communication errors in malfunction information,
installation of illegal modules, theft of data
version mismatch, backup failure, restoration failure, insufficient version
upgrades (incomplete operation)

traces of deleted information

pollution, insufficient recycling or reuse plans

errors in deleting personal information, operation history, etc.

theft of information/parts

Table 2. Dependability Obstructions

To identify these obstructions in embedded OS and other peripheral technologies, the table can bedivided into three areas:(1) Areas that should be covered by a process and/or organization (company) utilized by thedeveloper or service provider; as well as areas that should be covered in system integration.
(2) Areas where dependability technology is required for other OS-related components.
(3) Areas where large contributions to dependability can be expected from the OS and otherperipheral technologies.
These areas are respectively colored yellow, white, and orange in Table 2.
New techniques and technologies, along with traditional technologies such as CMMI, modern PM(Project Management) techniques, etc. need to be developed to address the problems posed by theabove faults in modern embedded devices in the 21st century. These are required for the proper
setting of requirements/specifications for design, development and testing. This difficult task mustbe accomplished, because with the development of large-scale software, embedded systems are nolonger considered mere stand-alone products but rather as fundamental parts of a whole
infrastructure that provides service to users through a network. The training of engineers and the
management for this purpose have become crucial.

10.2 Related Standards and Organizations
Standardy IEC 61508: Functional Safety
http://www.iec.ch/zone/fsafety/fsafety_entry.htm

Page 46
2010/12/01

Version 2.0a

DEOS Project
y
y

y
y

White Paper© 2010 Japan Science and Technology Agency

IEC 60300-1: Dependability Management
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=sea22.p&search=tex
t&searchfor=IEC+60300-1&submit=OK
IEC 60300-2: Dependability Program Elements and Tasks
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=sea22.p&search=tex
t&searchfor=IEC+60300-2&submit=OK
ISO/IEC 12207: Software Life Cycle Processes
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=21208
ISO/IEC 15288: System Life Cycle Processes
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43564

Process Guidey CMMI: Capability Maturity Model® Integration http://www.sei.cmu.edu/cmmi/
y DO-178B: Software Considerations in Airborne Systems and Equipment Certification
http://www.rtca.org/
y MISRA-C: http://www.misra-c.com/
y IEC 61713: Software dependability through the software life-cycle processes- Application guide
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=sea22.p&search=tex
t&searchfor=IEC+61713&submit=OK
y IEC 62347: Guidance on system dependability specifications
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=sea22.p&search=tex
t&searchfor=IEC+62347&submit=OK
Softwarey SELinux: Security-Enhanced Linux http://www.nsa.gov/research/selinux/index.shtml
y AppArmor®: a Linux application security framework
http://www.novell.com/linux/security/apparmor//y Xen® hypervisor: the powerful open source industry standard for virtualization
http://www.xen.org/
Related Organizations/Projects
y ISO: International Organization for Standardization http://www.iso.org/iso/home.htm
y IEC: International Electrotechnical Commission http://www.iec.ch/y ISO/IEC JTC1: Joint ISO/IEC Technical Committee 1
http://www.iso.org/iso/standards_development/technical_committees/list_of_iso_technical_com
mittees/iso_technical_committee.htm?commid=45020
y IEC/TC56: Technical Committee 56: IEC Technical Committee for International Standards inthe field of Dependability http://tc56.iec.ch/index-tc56.html
y OpenTC Consortium: Open Trusted Computing Consortiumy http://www.opentc.net/
y Linux-HA Project: High Availability Linux Project http://linux-ha.org/
y Carrier Grade Linux Workgroup：http://www.linuxfoundation.org/en/Carrier_Grade_Linuxy TCG: Trusted Computing Group https://www.trustedcomputinggroup.org/homey CELF: CE Linux Forum, an international open source software development community
http://www.celinuxforum.org/
y ERTOS Group: Embedded Real-Time Operating-Systems Group http://ertos.nicta.com.au/y ARTEMIS: Advanced Research & Technology for Embedded Intelligence and Systems
http://www.artemis.eu/
y CPS Program: Cyber-Physical Systems Program
http://www.nsf.gov/pubs/2008/nsf08611/nsf08611.htm
y MISRA: Motor Industry Software Reliability Association http://www.misra.org.uk/
y AUTOSAR: Automotive Open System Architecture http://www.autosar.org/
y JasPar: Japan Automotive Software Platform and Architecture https://www.jaspar.jp/
y FlexRay Consortium: Consortium for the communications system for advanced automotive
control applications http://www.flexray.com/
y NoTA: Network on Terminal Architecture http://www.notaworld.org/
y LIMO Foundation: Industry Consortium dedicated to Linux-based operating system for mobile
devices http://www.limofoundation.org/

2010/12/01

Version 2.0a

Page 47© 2010 Japan Science and Technology Agency

White Paper

DEOS Project10.3 DEOS Project Terminology
Availability: The ability of a system to keep a high operating ratio.
Reliability: The ability of a system to perform a specified function for an expected period of time.
Serviceability（Maintainability）: The ability to efficiently maintain a system, e.g. throughmodification, debug, and repair.
Integrity: The ability of a system to prevent improper system and data alteration.
Security: The protection of a system from external attack that causes degradation of availability,
reliability, serviceability, or integrity.
Dependability: Ability to deliver services that can justifiably be trusted. This is a composite ofavailability, reliability, safety, integrity and maintainability.
Open system: A system whose definition keeps changing during development or during operation
and/or whose operation may change with environmental changes such as connection toexternal systems through a network.
Closed system: A system which is isolated from other systems during operation, and whose system
requirements and configurations do not change during operation.
Black box: The systems or software components whose internal design is unknown and which is
integrated to a system based on external specifications only.
Legacy software: The software whose designers and maintainers are not available for maintenancebut which is still built-in and working in a system.
Incompleteness: The property of a system with incomplete requirement specifications, so that it isdifficult to fully understand as well as guarantee the system’s behavior upon shipment.
Uncertainty: The possibility that a system’s configuration will be changed by its usage environment
during the lifecycle of the system, making it difficult to completely predict the behavior of
the system during the design phase.
Open systems failure: Failure that is caused by incomplete and uncertain factors which are not clear
in the design phase. The possibility of these failures is inherent in embedded systems.
Open Systems Dependability: The ability to continuously perform measures that remove the factors
of failure before they cause failure, to provide appropriate and quick action when theyoccur, to manage the failure in order to minimize the damage so that the system can safely
and continuously provide the services expected by users to as great a degree as possible,
and to maintain accountability for the system operations and processes.
Manage: To solve a problem with efficient use of effort, and develop the state of the system in afavorable direction.
DEOS Process: Double helix process consists of the “requirements/environment change
accommodating cycle” and the “failure reacting cycle” to achieve open systems
dependability.

Page 48
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

D-Case Growth Cycle: A cycle in which D-Case expands and improves over time, which indicates
improvements in the system.
Requirement/Environment Change Accommodating Cycle: A cycle to respond and accommodate tochanges in stakeholders’ requirements or changes in environment.
Failure Reacting Cycle: A cycle to react to system failures.
System Change Requests based on Stakeholders’ Agreement: Requests to change systems withstakeholders’ agreement after discussion and resolution of the existing conflicts of change
requests among stakeholders.
Failure Prevention: To avoid system failure by predicting system failure and anomalies.
Responsive Action: To respond to system failure or to a problem system state as soon as possible
Normal Operation: Daily operation with appropriate periodical inspection and preventive
maintenance, and with effort to avoid the repeat of similar failures by performing
continuous improvement activities (Kaizen).
Achievement of Accountability: To deal with system failure by determining and explaining the cause,making a recovery plan, and explaining the current status and procedures taken clearly tothe stakeholders.
Cause Analysis: To identify the cause of failure or to identify areas of possible causes of failure basedon evidence.
Embedded System: A system with software within a system whose primary purpose is notcomputational.
System Architecture: A system’s concept, fundamental functions, and structure.
Elemental Technology: Technology to realize required functions.
Process: Steps for developing and operating systems or services, which include requirement
formulation, design, development, implementation, testing, operation and maintenancephases.
Metrics: Qualitative or quantitative indices to evaluate objects. Quantitative values are preferable,
because they facilitate comparisons and the certification of improvements.
Framework: D-fops is the framework of our project, which enables the construction of an architectureof Open Systems Dependability, to which are integrated the elemental technologies
enabling the required processes.
Standard: The functions achieving an objective, with the required level of performance and quality
defined.
Internationalization: To deploy certain concepts or technologies worldwide, not limiting the
deployment to a country or predefined area.
Consortium: A group of organizations or persons who share objectives and intend to cooperate toachieve those objectives.
Evidence: Valuable information which supports a claim through an argument.

2010/12/01

Version 2.0a

Page 49© 2010 Japan Science and Technology Agency

White Paper

DEOS Project

Virtualization Technology: Technology for managing computational resources by running an
abstraction of the system, and for enabling the logical partition of computational resources.
Formal Verification: To prove the correctness or incorrectness of programs by formal ormathematical methods.
Model Checking: Software verification technique that exhaustively checks whether a program works
correctly, without the occurrence of any critical error conditions such as deadlock or
infinite loop.
Type Checking: Software verification technique that identifies errors in a program on the basis of thepresence of explicitly or implicitly stated variable types.
Specification Description Language: A language which can describe the properties that a program
needs to satisfy.
TAL: Typed Assembly Language: Assembly language annotating types to values, which enables typechecking for proper memory management or flow count.

10.4 DEOS Project Members
Research Supervisor
Mario Tokoro, SONY Computer Science Laboratories, Inc.
Deputy Research Supervisor
Yoichi Muraoka, Waseda University
Area Advisors
Kazuo Iwano, IBM Japan, Ltd.
Tohru Kikuno, Osaka University
Kohichi Matsuda, Information-Technology Promotion Agency, Japan
Yoshiki Seo, NEC Laboratories America, Inc.
Hidehiko Tanaka, Institute of Information Security
Hiroto Yasuura, Kyushu University
Research Directors
Yutaka Ishikawa, University of Tokyo
Satoshi Kagami, National Institute of Advanced Industrial Science and Technology
Yoshiki Kinoshita, National Institute of Advanced Industrial Science and Technology
Kenji Kono, Keio University
Kimio Kuramitsu, Yokohama National University
Toshiyuki Maeda, University of Tokyo
Tatsuo Nakajima, Waseda University
Mitsuhisa Sato, University of Tsukuba
Hideyuki Tokuda, Keio University
Research Promotion Board Members
Nobuhiro Asai, IBM Japan, Ltd.
Tadashi Morita, Sony Corporation
Masamichi Nakagawa, Panasonic Corporation
Takeshi Ohno, Yokogawa Electric Corporation
Ichiro Yamaura, Fuji Xerox Co., Ltd.
Kazutoshi Yokoyama, NTT Data Corporation
Area Management Advisors

Page 50
2010/12/01

Version 2.0a

DEOS Project

White Paper© 2010 Japan Science and Technology Agency

Kazuo Kajimoto, Panasonic Corporation
Kazuyasu Sasuga, Fuji Xerox Co., Ltd.
Yuzuru Tanaka, Hokkaido University
Seishiro Tsuruho, HAL Tokyo
Dependable Embedded OS Research and Development Center
Makoto Yashiro, Japan Science and Technology Agency

2010/12/01

Version 2.0a

Page 51