This site defines a Multi-Aspect System Architecture for EPS products. Having multiple aspects or views helps to keep the model simple enough to be understand, but detailed enough information for formal or systematic analysis.

There are some well-known multiple-views architectures, such as the 4 + 1 Architectural View Model or even the OMG Systems Modeling Language (Figure 3. Structure - Behaviour - Requirements - Parametrics).

This microsite provides deep insight into each technical detail of the concept, allowing you to recognise and take advantage of a well-organised development and documentation system instead of using the existing one.

Table of Content

• Aspect : There are several different watching point of each artifact. Aspect means a particular direction of perspective. The aspect defines what is considered to the most relevant set of characteristics of the system to be emphasized while the rest of the characteristics are strongly simplified or even ignored.
• Resolution : The fineness of detail that can be distinguished from a given Aspect. This term is used as synonym for zoom-level referred to a specific aspect.
• View : What is revealed to the vision, or can be seen from a given aspect and from a given resolution. It is a particular projection of an artifact. The view is a simple Cartesian product of aspect and resolution: V = A x R.

• Requirement : A requirement is a statement about a solution for a system or one of its interface that describes a response to excitation, a time duration for a response, or even a physical property value like mass that shall be met by the solution.
• Feature : A feature is a small, granular function or characteristic expressed in
  client-valued terms as a satisfaction of one or even more requirements.

  A feature is a prominent or distinctive user-visible aspect, quality or
  characteristic of a system.

  One feature might realize one or more requirements, and one requirement
  might be realized by more than one feature.

• System Function : A System Function is a well-defined, encapsulated logical block identifying a coherent, unique functionality. A single System Function or a collaboration of multiple ones realize a Feature on a high abstraction level. SystemFunctions are reusable blocks among multiple Features.
  Each System Function is mapped to one and only one System Component.
• System Function Group (SFG) : The SFGs are disjunct sets of logically closely related System Functions from a system design point of view. As a rule of thumb, there are many relations within SFGs, while between two SFGs there are only few one or even none. It is possible, but not expected that each member of a SFG implements exactly the same Feature.
• System Component : System Components are the result of the system's functional breakdown. This functional breakdown structure is a hierarchical and incremental decomposition of the whole system, starting with the end objective and successively subdividing it into manageable components in terms of size and responsibility. The Torque Sensor Unit, Rotor Position Sensor are for example elements of the System Components.
• Interface : A region – e.g. point, surface, or volume – of connection between two engineering things, that for which observable, measurable, and reproducible properties or attribute can be obtained.
• Software Subsystem : The Software Subsystem is a well-defined, encapsulated part of the system identifying a coherent, unique functionality implementing the SW parts of one System Function Group. Software Subsystems are disjunct blocks of the SW Architecture.
• Software Component : The building blocks of the Detailed SW Architecture View are the Software Components.
• Software Module : It is related to defining a separately compiled unit from a source file and typically one or more associated header file.

  The concept of module comes from modular programming paradigm which advocates that software should be composed of separate, interchangeable components called modules by breaking down program functions into modules.

EMA defines the following aspects, resolutions and views, as the diagram shows below.

This aspect focuses on the expected functions and capabilities of the system, without considering their realization. Features describe the "problem space" (see the ).
This aspect has only system-level resolution.

System Features View

The view describes what is expected from the system, what functionality is to be provided in order to fulfill the product goals. The view characterizes the whole system by a set of features.

The following table contains the completed feature-list of the project R8-based BMW 35up.
(These links are available within the Intranet of ThyssenKrupp Presta.)

Expected Granularity:

The Functional Architecture describes the whole system from a solution perspective of high abstraction level by

• providing a high level solution concept for the entire system by breaking it down into logical blocks, and
• allocating these blocks to the appropriate elements of the System Component Breakdown Aspect.

The key building block of the Functional Architecture is the System Function.

A System Function can be characterized by

• the elements of the Component Breakdown Aspect they realize it,
• set of requirements of a feature which it fulfills as a result of requirement analysis. Note that it is possible that a particular System Function does not implement a customer-level requirement. This may typically be the case when a feature is realised by a large number of System Functions.
• brief list of responsibilities it has as a result of system design,
• extensions of requirements as a result of safety analysis methods
  such as functional ,

• simple uses relations between the System Functions.
• for structuring purposes System Functions may be grouped
  into System Function Groups.

Expected Granularity:

This aspect focuses on the physical breakdown of the system into physical components (see the ). It has only system-level resolution.

System Interfaces and Components View

This view describes the system boundaries and its most important – mostly hardware – building blocks. The view contains the

• system boundaries (System External Interfaces),
• main system components (also referenced as "elements of System Breakdown Structure" or "SBS elements"),
• optionally the internal interfaces between SBS elements (on the highest abstraction
  level only).

The view (and the aspect System Component Breakdown, as well) is based on preliminary knowledge about the product originated from

• earlier products or prototypes,
• strategic product management level decisions,
• critical hardware design decisions,
• key solution concepts (which kind of sensors to use, etc).

Expected Granularity:

This aspect focuses also onto the breakdown of the system into smaller components but it is more concrete and focuses only to the software parts of the system (see the ). The scope of this aspect is the software used within the System, including the software runs on

• the main microcontroller,
• the rotor turn counters of the electric motor – if the are any,
• the processor.

Software Architecture Aspect – High Level (low resolution) Software View

The view provides a high level perspective about the software elements of the system (see an example on the ). The most complex software runs on the ECU main microcontroller.

This High Level Software View is more detail-rich and more formal than the Functional Architecture Aspect but still has high abstraction level in order to remain comprehensive. The High Level Software View describes the software by

• breaking down into blocks (similarly to the Functional Architecture Aspect, but the scope and the relation of the components is more formalised,
• mapping these blocks to the System Functions.

A Software Subsystem is characterized by

• the System Functions and/or System Function Group(s) it realizes,
• the list of responsibilities/requirements it has to provide,
• the list of Services it provides to other Subsystems,
• the list of Services it requires from other subsystems in order to provide its functionality.

A Service offered to the other components is expressed as Provided Service and the need for service is expressed as a Required Service. The provided and required Services are represented as connection ports on a Software Subsystem.

The static mapping (actual usage) of provided and requested services is represented as connector on a diagram similar to a component diagram.

Expected Granularity:

Software Architecture Aspect – Low Level (high resolution) Software View

This view provides the most details about the software elements of the system. The View can be considered as a "zoom-into" of a Software Subsystem.

The representation of the Low Level Software View is a set of Software Component diagrams,

• created by either a known design tool (e.g. Enterprise Autosar), or
• created by any other tool for the non-AUTOSAR components.

Expected Granularity:

HiRes views can illustrate the relations among the different aspects.

EMA EMA is an acronym as EPS Multi-Aspect Archhitecture. EMA () are also small wooden plaques on which shinto worshippers write their prayers or wishes.