Definition of architecture

Based upon the text of
96P014 : [CIRP28]
JO WYNS, HENDRIK VAN BRUSSEL, PAUL VALCKENAERS, LUC BONGAERTS,
"Workstation Architecture in holonic manufacturing systems", Presented at 28th CIRP International Seminar on Manufacturing Systems, May 15-17, 1996, Johannesburg, South Africa, p220-231.
Accepted for publication in "Cirp journal on Manufacturing Systems" Vol.26, No 4

Webster's dictionary gives following definitions for architecture:

1. the art or practice of designing and building structures and especially habitable ones,
2. formation or construction as (or as if as) the result of a conscious act,
3. architectural product or work,
4. a method or style of building.

Architecture may refer to a product, e.g. the architecture of a building, or it may refer to a method or style, e.g. building architecture, the knowledge and styles used to design buildings. The remainder of this section discusses both interpretations and draws the analogy with «architecture of a building» and «building architecture." Finally, the specific architectural needs for reconfigurable systems are given, since the holonic workstation control system should be reconfigurable to respond to changing en vironments and demands.

System architecture

System architecture refers to the architecture of a specific construction or system. System architecture corresponds to "architecture as a product." It is the result of a design process for a specific system and specifies the functions of components, their interfaces, their interactions, and constraints. This specification is the basis for detailed design and implementation steps.

Defining an architecture for a system serves multiple objectives:

• It abstracts the description of complex dynamic systems by providing simple models. This way an architecture helps the designer in defining and controlling the interfaces and the integration of the system components [Zac87].
• During a re-design process, the architecture enables to reduce the impact of changes to as few modules as possible. The architectural model of a system allows to focus on the areas requiring major change.
• The architecture indicates the most vital system components and constructs that should not be violated when adapting the system to new uses. Violating the architecture - similar to removing load-bearing walls in a house - decreases the system's ability to change gracefully with changing constraints and requirements [PW92].
• The architecture is a means of communication during the design or re-design process. It may provide several abstract views on the system which serve as a discussion basis to clarify each party's perception of the problem area.

Drawing the analogy with the architecture of buildings (as in [PW92]) provides good insight in the characteristics of an architecture. It shows how architectures provide multiple views and abstractions, different architectural styles, and the important inf luence of both engineering principles and materials on the architecture of a building.

A building architect works with the customer by means of a number of different views in which some particular aspect of the building is emphasised. For example, there are elevations and floor plans that give exterior views and top views respectively. Scale models can be added to give the customer a good impression of the building. For the builder, the architect provides the same floor plans plus additional structural views that provide an immense amount of detail about various explicit design considerations such as electrical wiring, plumbing, heating, and air-conditioning. For the customer the most important views on a CIM-architecture are the ones focusing on system performance, user interface, maintainability, extendibility, etc. The designer of the syste m will be interested in detailed views on resource allocation, process planning, maintenance, monitoring and statistics, etc.

The architecture of a system can be formulated in a descriptive or in a prescriptive style. Descriptive style defines a particular codification of design elements and formal arrangements. The descriptive style is used during discussions between the client and the architect. Prescriptive style limits the set of design elements and their formal arrangements. This style is applied in plans used during the construction of a building, the constructor shall build according to plan.

The relationship between engineering principles and architectural style is fundamental. For example, one does not get the light, airy feel of a Gothic church from Romanesque engineering. It is not just a matter of aesthetics, also engineering principles as the use of buttresses are essential. Similarly, a re-configurable CIM-system cannot be built without a notion of object-oriented concepts as data-hiding.

Also the influence of materials is of major importance in enabling certain architectural styles. Materials have certain properties that are exploited in providing a particular style. One cannot build a modern stable skyscraper with wood and rope; concrete and iron are currently indispensable materials in realising this construction. Since CIM-architectures currently under development will rely on recent technologies (e.g. fast networking, distributed processing), they could not have been developed in the pa st.

Reference architecture

Reference architecture corresponds to "architecture as a style or method." It refers to a coherent design principle used in a specific domain. Examples of such architectures are the Gothic style for building and the AMRF-model for CIM [ABN81]. The architec ture describes the kinds of system components, their responsibilities, dependencies, possible interactions, and constraints. The reference architecture is the basis for designing the system architecture for a particular system. When designing a system acco rding to an architectural style, the architect can select from a set of well-known elements (standard parts) and use them in ways appropriate to the desired system architecture. [PW92]

The architecture gathers the principles and rules concerning system development in a specific domain, in order to achieve:

• a unified, unambiguous, and widely understood terminology,
• system architecture design simplicity, possibly allowing cheaper and faster design of the system architecture,
• higher quality systems by relying on proven concepts of the reference architecture,
• interfacing and possible re-usability of modules between different projects or system generations,
• development or implementation tasks which can be partitioned among different teams, ideally allowing each team to bring in their best expertise and available equipment,
• traceability between solution independent requirements and final realisations. The architecture shall clearly indicate and justify how and at what stage in the development process external constraints and engineering design decisions are introduced.

Successful achievement of these goals relies on the adoption of a clear and systematic methodology [Dor92, VW93].

Again, there exists an analogy with building architecture - the science, the methods, and the style of building. Since the architectural methods are a generalisation and abstraction of the architecture as a product, the remarks concerning multiple views an d abstractions, different architectural styles, and the important influence of both engineering principles and materials are equally valid. In this case however, architecture describes system domain elements, their functions and interactions, it does not d escribe how they actually function and interact in a specific system. For example, building architecture describes load-bearing walls as elements serving the goal of sustaining floors; it does not specify the weight a specific wall is able to carry.

Architectural needs for reconfigurable/flexible systems

A reconfigurable/flexible system is able to evolve according to changing needs; it enables easy re-design, and its functions can be extended. In other words, the system allows to add, remove and modify system components during system operation. Also, flexi ble systems minimise the need to adapt by maximising their range of 'normal' situations.

To this end, a reference architecture for reconfigurable/flexible systems shall specify:

• special elements to enable and support reconfiguration and adaptation. In a multi-agent manufacturing control system, this could be a 'yellow pages agent' who knows what system elements are present, where they are, and what services they offer.
• common characteristics of 'ordinary' system elements to support reconfiguration and adaptation. For instance, agents in a multi-agent manufacturing control system shall register with the yellow pages agent at installation and on explicit requests, and noti fy this agent of every relevant change.
• design rules to safeguard system flexibility. For instance, when designing a system element the developer shall not build on system constraints induced by other system elements with lower expected life-time; if not, the system will lock into (arbitrary) de sign choices which may need (non-arbitrary) revisions [Val93, VVB+95, BJT+95].

Moreover, the system architecture for reconfigurable/flexible systems has specific characteristics:

• in analogy with building architectures, the load-bearing elements are moved out of the way of the functional space. The 'flexible production hall' has as much free space as possible; a few pylons support a roof covering as large a surface as possible allow ing maximum accessibility. Note that a flexible system architecture gives little indication on how the system is used or even what customer service the system provides. It is no surprise that a flexible manufacturing control architecture leaves many questi ons unanswered; the opposite constitutes proof of inflexibility. Note also that the construction of such a 'flexible production hall' requires advanced construction technology.
• reconfiguration and adaptation often require spare capacity to provide a manoeuvring space. For instance, some buffer space is needed if a workstation that is temporarily unavailable during reconfiguration must not halt the entire production line.

Summary

A system architecture is an abstract description of a specific system. By indicating the functions of the system components, their interactions, and constraints, it helps to (re-)develop the system. The architecture depends on engineering principles and av ailable technology.

A reference architecture refers to coherent engineering and design principles used in a specific domain. A reference architecture aims at structuring the design of a system architecture by defining a unified terminology, describing the responsibilities of components, providing standard (template) components, giving example system architectures, defining a development methodology, etc.

The design of reconfigurable systems puts additional demands on the reference architecture, since the architecture shall allow to add, remove and modify system components during system operation.

References

Abstracts of PMA publications can be found at http://www.mech.kuleuven.ac.be/pma/pubs/pubs.html.

Or specific for the HMS-publications, look at http://www.mech.kuleuven.ac.be/pma/project/goa/pubs.htm

[ABN81] Albus, J.S., Barbera, A.J., Nagel, R.N., Theory and practice of hierarchical control, Proceedings of the 23th IEEE Computer Society International Conference, Washington, USA, pp18-39.

[Are95] Arentsen, A.L. A generic architecture for Factory Activity Control, PhD. thesis University of Twente, 1995

[BJT+95] BONGAERTS, L., JORDAN, P., TIMMERMANS, P., VALCKENAERS, P., WYNS, J., Evolutionary Developments in Shop Floor Control, Co-operation in Manufacturing: CIM AT WORK (Preprint), Kaatsheuvel, The Netherlands, August 28-30, 1995, page 287-300.

[BVV+95] BONGAERTS, L., VALCKENAERS, P., VAN BRUSSEL, H., WYNS, J., Schedule Execution for a Holonic Shop Floor Control System, Preprints of the Advanced Summer Institute (ASI) 95 of the N.O.E. on Intelligent Control of Integrated Manufacturing Systems, L isboa, Portugal, 24/6/95

[DBW91] DILTS, D.M., BOYD, N.P., WHORMS,H.H., The Evolution of Control Architectures for Automated Manufacturing Systems, Journal of Manufacturing Systems, Vol. 10, N. 1, 1991.

[Det93] DETAND, J., "A Computer Aided Process Planning System Generating Non-Linear Process Plans", PhD Thesis, KU Leuven, October 1993 (ISBN 90-73802-23-7).

[Dor92] Dornier GmbH, A&R Control Development Methodology Definition Report, Doc. Nr. CT2/CDR/DO, Issue 2.0, Sept. 1, 1992

[CIRP94] VAN BRUSSEL, H, VALCKENAERS, P., BONNEVILLE, F., Programming, Scheduling and Control of Flexible Assembly Systems, in Manufacturing Systems, Vol. 23, No. 1, pp. 25-36, 1994 (18 pages).

[Koe89] KOESTLER, A., The Ghost in the Machine, Arkana Books, 1989

[PW92] PERRY, D.E.,.WOLF, A.L, Foundations for the Study of Software Architecture, ACM SIGSOFT, Vol17, No 4, Oct 1992, p40-52.

[Sim90] SIMON, H.A., The sciences of the artificial, 2nd ed., MIT Press Cambridge (Mass.), 1990

[SHJ93] SMITH, J.S., HOBERECHT, W.C., JOSHI, S,B, A Shop Floor Control Architecture for Computer Integrated Manufacturing, Texas A&M University and Pennsylvania State University, 1993

[TDK95] TANAYA, P.I., DETAND, J., KRUTH, J.P., Holonic Machine Controller: a study and implementation of holonic behaviour to current NC controller, Co-operation in Manufacturing: CIM AT WORK (Preprint), Kaatsheuvel, The Netherlands, August 28-30, 1995, p age 375-396.

[Val93] VALCKENAERS, P., Flexibility for Integrated Production Automation, PhD. thesis K.U.Leuven, 1993

[VBV+94] VALCKENAERS, P., BONNEVILLE, F., VAN BRUSSEL, H., BONGAERTS, L., WYNS, J., Results of the Holonic Control System Benchmark at KULeuven, Rensselaer's 4th International Conference on Computer Intergrated Manufacturing and Automation Technology (CIM AT), proceedings, Rensselaer's Polytechnic Institute, New York, USA, October 1994

[VVB+94] VALCKENAERS, P., VAN BRUSSEL, H., BONNEVILLE, F., BONGAERTS, L., WYNS, J., IMS Test Case 5: Holonic Manufacturing Systems, Pre-prints of IMS'94, IFAC workshop, Vienna 13-15 June 1994.

[VVB+95] VAN BRUSSEL, H., VALCKENAERS, P., BONGAERTS, L., WYNS, J., Architectural and System Design issues in Holonic Manufacturing Systems, Pre-prints of IMS'95, IFAC workshop, Bucharest, Romania, October 1995.

[VW93] VERSAVEL, D., WYNS, J., Application of the A&R Control Development Methodology, Thesis 93EP4, K.U.Leuven, 1993

[Zac87] Zachman, J.A., A framework for information systems architecture, IBM Systems Journal, Vol. 26, No 3, 1987, p 276-292.

Copyright 1996, Katholieke Universiteit Leuven
Page design: Jo Wyns
Information provider: PMA Division KULeuven
Comments for the authors: Jo Wyns
http://www.mech.kuleuven.ac.be/pma/project/goa/extracts/architec.htm