Architecture Modeling - SPES 2020

Architecture Modeling
and are gradually enlarging their scope towards other perspectives, such as reflected in the move
by Dassault Systems 1 to integrate UML modeling tools, or their recent acquisition of Geensoft.
Vendors of modeling and specification tools offer increasingly higher abstraction levels supported
with simulation, analysis, and synthesis capabilities, and are increasingly opening their
tools to allow integration into tool chains to cover the complete design space. Environments
such as Eclipse have been instrumental in such tool integration activities.
5.1.2 Perspectives and abstraction layers in system-level design
The geometric perspective is offered to cover the physical layout of the system-underdevelopment.
As mentioned above, this is the classical domain of tools such as CATIA 2 or
the Siemens PLM suite 3 . While clearly the 3D design of products is out of scope of SPES, the
constraints coming from this, and in particular the concrete positioning of components of the
technical architecture as well as their interconnection, are of key relevance, since they impact
non-functional aspects and induce locally constraints.
Within the technical perspective, we propose to capture all design artifacts which jointly
support the realization of a new product function and which have a one-to-one correspondence
to physical entities in the geometric domain. By the fact that system-development processes
address the realization of functions of the complete product under given quality requirements
(notably safety), all aspects of hydraulic and mechanical subsystems relevant to achieving this
must be assessed to a level of detail ensuring sufficient observability by the supporting embedded
systems to assess their health status and react to this. Thus, at higher abstraction levels, the
internal realization of a system in terms of mechanical, hydraulic, and electronic subsystems are
visible, in our proposal as rich components, thus not only specifying interfaces between these,
but as well for all relevant aspects of the design contracts formalizing what each subsystem is
assuming to be guaranteed by other subsystems. E.g. for the safety aspect, such contracts would
characterize the class and probabilities of failures assumed by the electronic subsystem both wrt
the mechanical and the hydraulic subsystems.
Within the scope of SPES, we would assume that lower abstraction layers focus on refining,
then, the internal structure of the electronic subsystem. At some layer (which in the EDA
domain was called the system layer), this would e. g. depict the electronic architecture of a
car, in terms of a FlexRay backbone bus 4 , interconnected via bridges to subsystems dedicated
to specific “domains” such as body electronic, power-train, infotainment, stability, etc. with
domain specific bus-systems, as well as the electronic control units and intelligent sensors and
actuators linked to these, and employ the AUTOSAR meta-model to characterize these as well
as the computing resources inside electronic control units.
Within the operational perspective, we suggest, for each level of abstraction, to capture the
interactions at the system boundary of the system under development. This includes, on the
highest “product” level, a specification of the operational scenarios which must be supported
by the product (hence the naming of the perspective), such as the different classes of missions
for a military aircraft, or the characteristics and variances of product processes to be supported
in product automation applications. Other examples of operational scenarios to be supported
relate to maintenance, or to the production of the product itself (to identify requirements on
the design enabling particular production steps). In general, in this perspective and at this
1 http://www.3ds.com/
2 http://www.3ds.com/catia
3 http://www.plm.automation.siemens.com/en us/products/teamcenter/
4 http://www.flexray.com/
70/ 156