Principle of stepwise decomposition
From a system theory point of view, an architecture is a specification of a system. This system can be composed of subsystems and aspect systems.
Subsystems form a structure decomposition of a system: a set of sub-systems together form the super-system. Subsystems form a partition of a system: every element of the super-system is part of exactly one subsystem (this means that nothing is forgotten or replicated). To illustrate the concept, one can think of partitioning a house into multiple rooms: the house is the super-system formed by the combination of the rooms which are the subsystems. We will see later in this document that decomposition into sub-systems is a powerful way to deal with the complexity of the HORSE architecture. In designing a stepwise structural decomposition of an architecture, we traverse aggregation levels of that architecture [Gref15]: we move from a highly aggregated specification to a highly detailed specification.
Aspect systems form a characteristics decomposition of a system: a set of aspect systems together describe the structure and behavior of a system. The set of aspects provides a separation of concerns: we can look at each aspect of a system individually. To illustrate this concept, one can think of the exterior design of a house versus the interior design: they are two aspects that describe characteristics of the same house, yet different aspects. We will see later in this document that working with aspects is also a powerful way to deal with the complexity of architectures.
Apart from structural decomposition and characteristics decomposition, we may also need several levels of abstraction [Gref15]. A highly abstract architecture is specified in general terms, such that it can be applied in multiple contexts (few context-specific parameters have been filled in, such as specific technology characteristics). A highly concrete architecture is specified in very specific terms, such that it matches one specific context (application scenario). In HORSE, we may need abstract architecture specifications that are applicable to multiple contexts, which are made specific to fit a specific pilot case.
HORSE architecture levels
Figure 1: HORSE architecture levels
Level 0
In the HORSE project, we develop a system for support of advanced manufacturing processes. These manufacturing processes take place as part of end-to-end business processes, i.e., processes starting at customer orders and ending in after-sales service. As such, various enterprise-level functions are linked, as modelled for instance in Porter’s value chain model [Port85].
This means that the HORSE system will run in the context of other enterprise information systems supporting these processes, such as:
- enterprise-level business process management system (BPMS), which contains functionality to manage business processes across the various enterprise information systems;
- enterprise resource planning system (ERP), which contains functionality for the management/planning of customer orders, organizational resources, etc.;
- manufacturing execution system (MES), which contains functionality for the management of manufacturing resources;
- product lifecycle management system (PLMS), which contains functionality for the specification of products to be manufactured.
Consequently, it is a good idea to architecturally embed the HORSE system in an enterprise architecture context. As the exact enterprise information system context is dependent on a specific organization, we remain with a high-level, abstract software architecture here. This is shown in Figure 2.
Figure 2: Logical software architecture aggregation level 0
Level 1
The HORSE system must support both manufacturing processes across manufacturing cells and manufacturing steps within manufacturing cells. Typically, one manufacturing process uses a number of manufacturing cells - the process coordinates, the cells perform the actual work. This means that there are manufacturing activities at two distinct levels with different characteristics. Consequently, the HORSE software architecture has two levels as well, which we call HORSE Global and HORSE Local. We use these two levels to decompose the HORSE software architecture at aggregation level 0 (projected onto the HORSE system only) into the software architecture at aggregation level 1 - shown in Figure 3.
Figure 3: Logical software architecture aggregation level 1
We can map the HORSE Global and HORSE Local levels again to the IEC manufacturing hierarchy (focused on discrete production) [IEC]. This is shown in Figure 3a. Here we see that HORSE Global covers the site, area and production line levels of the hierarchy (as all these levels require coordination between work cells). HORSE Local covers the work cell level.
Figure 3a: IEC manufacturing hierarchy mapped to HORSE Global and Local levels
Level 2
The HORSE system must support both manufacturing processes across manufacturing cells and manufacturing steps within manufacturing cells. Typically, one manufacturing process uses a number of manufacturing cells - the process coordinates, the cells perform the actual work. This means that there are manufacturing activities at two distinct levels with different characteristics. Consequently, the HORSE software architecture has two levels as well, which we call HORSE Global and HORSE Local.
Manufacturing activities need to be designed or configured (to parameterize systems for specific production) and to be executed (to actually manufacture products). This means that the HORSE architecture needs to include modules for design/configuration and modules for execution. This holds both at the HORSE Global and HORSE Local levels. This leads to a software architecture with four modules, as shown in Figure 4: two levels with each two modules.
Figure 4: Logical software architecture Level 1 and 2
For more details and elaboration about the HORSE logical architecture the reader is directed to deliverable D2.2: Complete System Design
Level 3
At aggregation level 3 of the logical software architecture, we elaborate each of the four functional modules identified at level 2.
Figure 5: Overall logical software architecture, aggregation level 3 (Product Defs. DB and interfaces to platform/operators omitted)
HORSE Design Global
The HORSE Design Global subsystem contains functionality to design manufacturing activities at the global level, i.e., at the site, area and production line levels. This design involves two aspects:
- design of the manufacturing processes, i.e., what needs to happen in which order and with what requirements to the agents involved (role specifications);
- design of manufacturing agents, i.e., the humans and machines (robots and other relevant automated machines) with their characteristics.
The two aspects are mapped to two logical software modules at this aggregation level. These software modules interact through the Process Definitions database (i.e., this subsystem has a data-centered architecture).
The resulting architecture is shown in Figure 6.
Figure 6: Logical software architecture aggregation level 3, subsystem 1
HORSE Exec Global
The HORSE Exec Global subsystem is responsible for manufacturing activities across work cells, i.e., at the site, area and production line levels (see Figure 3a). This involves two main functions:
- supporting execution of manufacturing processes, i.e., making things happen;
- supporting awareness about the global state of execution, i.e., observe things that happen and processing this into relevant signals for controlling execution.
Both main functions are allocated to logical software modules at this aggregation level. We label the execution module Manufacturing Process Management System (MPMS), as a variation of a standard Business Process Management System (BPMS, mostly applied in the administrative domain).
It is important that design decisions w.r.t. the internals of the HORSE Exec Global module (either in the logical architecture or later in the development and process architectures) are as much as possible isolated from design decisions in the HORSE Exec Local module. For this reason, we include an abstraction layer (Exec Global Abstraction layer) in the interface to the HORSE Exec Local subsystem.
The above decisions lead to the logical HORSE Exec Global architecture shown in Figure 7. The architecture also shows the contextual connections following from the software architecture at Level 2 (see Figure 15).
Figure 7: Logical software architecture aggregation level 3, subsystem 2
HORSE Config Local
The HORSE Config Local subsystem contains functionality to design manufacturing activities at the local level, i.e., at the work cell level (see Figure 3a). This design involves three main aspects:
- configuration of manufacturing tasks, i.e., the high-level activity spanning a work cell; note that this may require multiple agents of different kinds that each execute manufacturing steps (e.g. a human and a cobot);
- configuration of manufacturing steps, i.e., the low-level procedures performed by humans and machines (robots and other relevant automated machines);
- design of workcells.
The three aspects are mapped to four logical software modules at this aggregation level (by distinguishing between human step design and automated step design, as these require different functionalities). These software modules interact through the Task/Step/Cell Definitions database (i.e., this subsystem has a data-centered architecture).
The resulting architecture is shown in Figure 8. Note that the Process Definitions database is only connected to the Task Design module, as tasks are embedded in processes (and steps are embedded in tasks).
Figure 8: Logical software architecture aggregation level 3, subsystem 3
HORSE Exec Local
The HORSE Exec Local subsystem is responsible for manufacturing activities within individual work cells, i.e., at the work cell level (see Figure 3a). This involves two main functions:
- supporting execution of manufacturing tasks and steps, i.e., making things happen;
- supporting awareness about the state of execution, i.e., observe things that happen and processing this into relevant signals for controlling execution.
Both main functions are allocated to logical software modules at this aggregation level. Note that this design decision is isomorphic to the one for the HORSE Exec Global subsystem (see Deliverable D2.2).
It is important that design decisions w.r.t. the internals of the HORSE Exec Local module (either in the logical architecture or later in the development and process architectures) are as much as possible isolated from design decisions in the HORSE Exec Global module. For this reason, we include an abstraction layer (Exec Local Abstraction layer) in the interface to the HORSE Exec Global subsystem. Note that this decision is symmetric w.r.t. the design of the HORSE Exec Global subsystem (see Deliverable D2.2).
The above decisions lead to the logical HORSE Exec Local architecture shown in Figure 9.
Figure 9: Logical software architecture aggregation level 3, subsystem 4
[Gref15]: P. Grefen; Business Information System Architecture (Version Spring 2015); Eindhoven University of Technology, 2015.
[Port85] M. Porter; Competitive Advantage: Creating and Sustaining Superior Performance; Free Press, 1985.
[IEC] Enterprise-Control System Integration - Part 1: Models and Terminology, 2nd ed.; The International Electrotechnical Commission (IEC), Geneva, Switzerland, 2013.
