executing function, might be the output of a function Fine Planning and part of the input of the function that controls that specific executing element. The interaction between these two functions is the one-way exchange of jobs and --- possibly --- the feedback of monitoring information. A rather obvious example of a constraint is that the set of jobs allocated to production resources must be similar to the set of jobs that is input to the fine planning component. The following is an example of a dynamic constraint, which originates from a desire to fully utilise a specific executing element, say $M$.

For each system state $i$ must hold that, if in state $i$ jobs are available that might be executed on $M$, and if $M$ is idle, it is not allowed that in state $i+1$ resource $M$ is still idle. This constraint specifies the priority of resource $M$ over other resources \cite{17}.

The design of the solutions that embody these constraints should not be part of the architecture design.

An architecture can be looked at from different points of view. Apart from looking at a control architecture from a functional viewpoint, a designer has to take into account other aspects as well. For instance, a designer wants to be able to concentrate on the structure of information objects --- such as the jobs in the previous example --- and the relationships between them. It follows that several aspects of architectures are relevant to the overall design task, and that a designer has to construct a number of models. Each of these models omits those aspects of the system under study which are considered not to be relevant for the present purposes, and tends to concentrate on one single aspect of the architecture in question (i.e., aspect models). The use of a set of models allows the designer to deal with a number of relations between the essential elements of the system under construction.

\section{Requirements on modelling techniques}

Based on literature and on our own experience, we have identified a number of requirements a modelling technique has to fulfil in order to support a designer in the specification of control architectures \cite{18,19}. In Section 5, these requirements are illustrated and explained in more details. Note that the following set is not pretended to be exhaustive.

The main requirement is that the technique should be able to appropriately express the architectural characteristics of a system as described in the previous section. This means that the technique has to provide the ability to specify concurrent processes, the interactions between these processes in terms of exchange of messages and products, and the process behaviour. In addition, constraints on system states (static constraints) as well as constraints on changes of states (dynamic constraints) have to be specified. The technique should provide multiple views on an architecture, and modelling should result in architecture specifications that are independent of implementation concerns. The technique should be based on a formal model to unambiguously specify the architecture under design, and it should be supported by a software tool. Finally, an accompanying methodology should guide a user in the modelling process.

\section{CIMOSA modelling framework}

In Fig.~\ref{figure_1}, the modelling framework is represented by the CIMOSA cube. The cube offers the ability to model different aspects and views of an enterprise \cite{1,2}. This three-dimensional framework has a dimension of genericity, a dimension of enterprise models, and a dimension of views:

\begin{itemize}
\item The genericity dimension is concerned with the degree of particularisation. It goes from generic building blocks to their aggregation into a model of a specific enterprise domain
\item The modelling dimension provides the modelling support for the system life cycle, starting from
\end{itemize}

\begin{figure}[h]
\centering
\includegraphics{figure_1.pdf}
\caption{CIMOSA modelling framework.}
\label{figure_1}
\end{figure}