Architecture Modeling - SPES 2020

Architecture Modeling
OEMs are increasingly using models within procurement processes, typically safeguarding
themselves against potential liability issues by requiring suppliers to validate such models
against textual requirement specifications. A re-appearing reason for failures causing deep iterations
across supply chain boundaries rests in incomplete characterizations of the environment
of the system to be developed by the supplier, such as missing information about failure modes
and failure rates, missing information on possible sources for interferences through shared resources,
missing boundary conditions, etc. This highlights the need to explicate assumptions on
the design context in OEM-supplier contracts. This key need was one of the major motivations
for introducing the contract-based design methodology for embedded systems, as initially developed
in the Integrated Project SPEEDS. In enforcing the analysis of the key characteristics of
the environment required to enforce the system specification up front, responsibilities between
what has to be guaranteed by the OEM (that the system provided by the supplier will be embedded
in an overall design meeting the assumptions on the environment specified in the contract)
and the supplier (in providing an implementation to the system specification provided that the
system is used in a context meeting the specified environment characteristics) are clearly defined.
In the light of an increased sharing of hardware resources by applications developed by
multiple suppliers, such a contract-based approach seems indispensable for resolving liability
issues and allowing co-existence of applications with different criticality levels (such as ASIL
levels in automotive).
In domains developing safety related systems, domain specific standards clearly define the responsibilities
and duties of companies across the supply chain to demonstrate functional safety,
such as in the ISO 26262 for the automotive domain, IEC 61508 for automation, its derivatives
Cenelec EN 50128 and 50126 for rail, and Do 178 B for civil avionics.
The challenge in defining standards rests in balancing the need for stability with the need of
not blocking process innovations seen as indispensible to cope with the exponential growth in
systems complexity and the overarching need of optimization techniques for cost reduction. As
an example, means for compositional construction of safety cases thus allowing modular certification
are seen as mandatory to reduce certification costs in the aerospace and rail domains.
Similarly, the potential of using formal verification techniques to cope with increasing system
complexity will lead to an adaptation of the current DO 178 B standard, establishing the role
of these techniques within the construction of safety cases. In general, this calls for a closed
feedback loop between design and safety processes, assessment the potential impact and benefit
of such design representations and enabled process optimizations on safety standards, and identifying
techniques with strong optimization potential and high industrial relevance early enough
for adaptation of standards enabling their usage in safety-critical system design.
5.2.3 Getting Initial Requirements Right
Depending on application domains, up to 50% of all errors result from imprecise, incomplete,
or inconsistent requirements. Out of the many approaches taken in industry for getting requirements
right, we focus here on those for initial systems requirements, relying on ISO 26262
compliant approaches such as discussed in the context of virtual system integration to systematically
reduce system contracts to contracts on subsystems which are jointly powerful enough
to establish the total set of system contracts.
To cope with the inherently unstructured problem of (in-)completeness of requirements, industry
has set up domain- and application-class specific methodologies striving towards completeness
of requirement analysis. As particular examples, we mention learning process, such as
employed by Airbus to incorporate the knowledge base of what is called external hazards from
101/ 156