This functionality is only available for certain module packages.

You are here: Tutorial > Example Feeder > Architecture model

Architecture model

In order to be able to combine and reuse library components in any project, a company must define general structures based on which components are developed and used. This is done by means of an architecture model.

Terms such as function group and function have already been used in the feeder description. They correspond to a definition of hierarchical levels in a machine or plant specified by the Esslingen University of Applied Sciences for the feeder components. Other companies may, for example, alternatively use units, modules, or segments.

Rules that are used as the basis for the modular system of feeders:

Under these rules, a function group or station is, for example, not permitted to contain a sensor.

The formal mapping of these rules in a library that defines the architecture model is shown in the following diagram:

The rule for permitted sublevels is formalized using the is a permitted sublevel of relationship (shown using a dashed line and a filled rhombus), for example between Functiongroup and Functionunit.

This property is inherited by all derived components (e.g., insert and separator). Because all library components inherit from an architecture model component, the rules apply to all modular system developers; in other words, a modular system developer cannot, for example, create a function group that contains a sensor.

The following sections show step-by-step how to model the architecture model introduced in this section, the modular system, and the feeder project in EEC.

The individual steps are structured as follows: