Dependable embedded systems: roadmaps and challenges

advertisement
Dependable embedded
systems: roadmaps and
challenges
Robin E Bloomfield
Adelard and City University
reb@adelard.com
Accompanying Measure in
System Dependability
Dependability Roadmap
Robin E Bloomfield, Adelard and City University
Marcelo Masera, JRC
and many others ..
Development of way ahead
Issues from scenarios and other
roadmaps developed into capabilities
~25-30
Sketch of existing abilities for each
capability
Developed a gap analysis
Mix in FW6 priorities, rationale and
our own ideas à
Priorities for action, timeline
Key capabilities
Category 1 – Evolution and dynamics To understand,
evaluate and predict the behaviour of large dynamic (AmI)
socio-technical systems of systems
Category 2 – Design, development and evaluation To be able
to design, develop and evaluate cost-effective systems and
components that are adequately dependable
Category 3 – Meta-data To understand, design, develop and
evaluate meta-knowledge and meta-data
Category 4 – New threats and vulnerabilities To understand,
evaluate and predict new threats and vulnerabilities
Category 5 – Risk Issues. To be able to understand,
evaluate, communicate, control, remove and mitigate the
risks associated with the AmI vision.
Category 6 – Multi-disciplinary approach.
Within each category we elaborate ~5-10 specific capabilities
Gap analysis
Capability required
c3 Ability to characterise required
and achieved dependability in user terms and to link to the
dependability characteristics of the underlying services
Current profile Techniques for user views of properties
such as design, functionality well established (industrial
design, focus groups, prototype); dependability of large
industrial/aerospace/defence systems well articulated but
evaluation of achievement harder
Summary of gap Difficult to translate user views of trust,
safety, security into requirements for underlying services;
issues of discovery, shaping, elicitation, transformation.
Requires some transfer and adaptation of high dependability
work but also more fundamental mixture of sociological,
psychological, engineering and computer science.
Policy context – shaping
factors
•
•
•
•
technology strategic, so
need diversity of supply
changing threats means that
society needs contingencies and
local (regional, national) resilience
can not afford to re-engineer
peculiarities that will
infrastructures for generations
not be served by the
so have to get it right
global market
potential large market but
individual groups not significant
no single player can
enough from a market view or
afford/ has the power to
needs not addressed by global
develop it
market
large systemic risks that
need reinsurance/
regulation
Developing a multi-disciplinary dependability community by empirical
studies, joint program of work, addressing fundamental concepts.
Does not exist at the moment.
!Understand the boundary-less nature of systems and their failure
behaviour with a need for modelling, data collection,
experimentation, assessing systemic risks, and the possibility of
emergent behaviour and surprise.
Understanding new risks and threats arising from the dynamic and
evolutionary nature of the systems and their environments.
Developing existing dependability technologies to deal with
increased scale and complexity and criticality (telecoms, embedded,
smart cards) – emphasis on critical components
Developing theories, methods, tools for the design, development and
evaluation of AmI systems and existing systems in the changed
threat environment – emphasis on composability
Understanding and assessing trust, risk and responsibility, predicting
trust relationships and developing methods for users – oriented
dependability risk assessments
Dependability of meta-data
Conclusions from Roadmap
Attempt at comprehensive and multicommunity elicitation of dependability
issues
Augmented with scenarios and statements of
state of art
Sketch of current capabilities and gap
analysis
Recommendations for research priorities,
timeline - given FP6 and market context
Need to cluster and map capabilities to a
convincing, focused project
Available from www.am-sd.org.
Some lessons
Future often seen only
in terms of success
Failure, exclusion not
attractive
Non-failure not a good
demo to policy makers
Too often defined in
terms of incremental
improvements, shopping
list of research topics
and some more..
Could be important
activity for a community
Small steps towards a
future and find no easy way
back
market does not
support alternatives
need to address darkside but not be
excluded from debate
Risks and threats socially shaped
impact all our work
technical, policy, market
omnipresent intelligent adversary vs
blundering violations
tolerance to different consequences
(loss of identity, connectivity, ..)
Scenarios
Importance of scenarios to define the future
selection not neutral (e.g. road
warrior)
powerful images
Need our own scenarios
convincing,short,accessible
need methods for analysis and relating to
system, sub-system and components
Define the future
Need to define a view of modernity, what is
taken as obvious, not changeable, selffulfilling
use of certain products
always on, AmI vision
“the computer’s not working”
good software expensive
public domain evidence, open source?
limits to our knowledge
stand up for good design
Download