Complexity metrics for manufacturing control architectures based on software and information flow
Introduction
Manufacturing enterprises are increasingly driven by a complex combination of software systems that need to be integrated for the overall business to be competitive. Software systems are used to control important aspects of a manufacturing enterprise ranging from sales and marketing to production and logistics. As the software systems become larger, the difficulty of locating and correcting problems rises exponentially. Usually over 70% of the effort in software development is directed towards testing and maintenance. Studies have pointed out that software complexity is the major reason for rapidly increasing software development costs. (Ramamoorthy, Tsai, Yamaura, & Bhide, 1985). This has motivated researchers to develop comprehensive metrics to ‘measure’ the quality of software. Software architectures specify interconnection structures and define the interface between various inter-operating components of a system (Bauer, Bowden, Browne, Duggan, & Lyons, 1991). These architectures directly influence the flow of control, the monitoring of information and the interaction between the various components and hence define the way systems operate to satisfy their goals. Thus there is a need for tools that allow a designer to be able to quantify the ‘better’ alternative among a set of solutions or to get insights into the potential ‘stress’ points in the design. The first step in building this tool is to identify the measurement goals and properties of the system that need to be quantified (Rombach, 1990). Components that typically determine the complexity in a manufacturing system are as follows (Bermejo, Calinescu, Efstathiou, & Schirn, 1998):
- •
The product structure
- •
Structure of the shop or plant
- •
Planning and scheduling functions
- •
Information flow
- •
The dynamism, variability and uncertainty of the environment
- •
Other functions within the organization
Organizations can be defined as an arena where human beings come together to perform complex tasks so as to fulfill common goal(s) (Narayanan & Nath, 1993). Every organized activity gives rise to fundamental requirements involving division of labor into various tasks to be performed and coordination of tasks to accomplish the activity. Coordination involves the following mechanisms (Mintzberg, 1979):
- •
Mutual adjustment: coordination of work by the process of informal communication and control of work rests with the doers.
- •
Direct supervision: coordination by having one individual take responsibility for the work of others, issuing instructions to them and monitoring their actions.
- •
Coordination by standardization: standardization establishes coordination between parts by reducing the need for continuing communication.
For about half of the 20th century, organization structure was ruled by a set of official, standardized work relationships built around a tight system of formal authority (Robbins, 1987). A firm's structure is closely related to its technical system of production. For example, mass production firms seem to require the formal type of structure; firms in unit and process production seem to require a looser structure, more reliant on mutual adjustment. The size of an organization best explains the many characteristics of the structure. For example, the larger the organization, the more important was standardization as a coordinating mechanism.
Increasing reliance on software to automate the traditionally human-driven coordination has led to a variety of control architectures (Dilts, Boyd, & Whorms, 1991). Architectures used in different manufacturing system software range from hierarchical client/server to fully distributed peer-to peer. Client/server architectures are in wide use today to support hierarchical structure required for MRP/ERP type applications. A peer-to-peer architecture is different from the traditional client/server architecture because the software entities involved act as both clients and servers. Every entity in the system not only can request information from other servers, but they also have the ability to act as a server and respond to requests for information from other clients at the same time. Distributed peer-to-peer architectures can be easily constructed and scaled using open architecture, computing and networking equipment. By ‘open architecture’ we mean an architecture whose specifications are not proprietary to the developer. This includes officially approved standards as well as privately designed architectures whose specifications are made public. Several experimental implementations of distributed architectures have shown that they tend to reduce complexity, which in turn increases scalability, flexibility, fault-tolerance and modifiability. There is a need to develop metrics to quantify complexity in such systems to evaluate alternatives at the design stage.
In this paper, we propose metrics to quantify the complexity of manufacturing control architecture based on the software and information flow in the system. In Section 2, relevant metrics from software engineering are reviewed. Section 3 presents metrics for manufacturing control architecture complexity. Section 4 reviews metrics for inter-module complexity, intra-module complexity and a new metric for complexity of scale is proposed. In Section 5, the proposed complexity metrics are applied to a high-speed material delivery control system and the resulting measures are used to objectively compare a hierarchical and a heterarchical architecture. After this complexity metrics are applied to measure the complexity of a real-time distributed scheduling system. The paper is concluded with suggestions for future research.
Section snippets
Software metrics
The motivation for software metrics arises from the need for quantitative and analytical approaches for software engineering. Software metrics attempt to provide a means to compare different techniques and designs in terms of cost, effort, maintenance, understandability and reliability to supply meaningful and timely project management information. A more flexible system might mean a more complex system, but not necessarily a system that is harder to understand or to maintain (Liu, Chien, & Ho,
Metrics for manufacturing control architecture
A software architecture not only needs to provide a satisfactory solution to the problem at hand but also consider factors such as the effort and cost involved in implementation, maintenance, reusability, flexibility, etc. For example, an increase in flexibility would provide such benefits as increased production, product customization, etc.
The proposed system of metrics is intended to help in identifying potential stress points of the architecture. The basis of complexity that results in
Complexity metrics
The metric proposed in this research combines the Inter- Module and Intra-Module complexity of the components. The fundamental principle behind the proposed metrics is that the complexity of a system is composed of two attributes—the internal complexity of a module and the complexity of its interaction with the environment—and is expressed as follows (Henry & Kafura, 1981):
Squaring the inter-module complexity characterizes the fact that
Case studies
We present two cases where the proposed complexity metrics are applied after implementation. The intent is to quantify the ‘gut feel’ of the designers and to assess the usefulness of these metrics for future designs. The first case is a High Speed Material Transfer Network system (Duffie & Prabhu, 1995). The second case is a Distributed Scheduling system. (Prabhu, Cho, & Koomsap, 1999) The case studies provide some validation of the proposed metrics for quantifying complexity of manufacturing
Conclusions and future work
This paper shows the need for complexity metrics in development of manufacturing control architecture and its software. The metrics serve as a design feedback mechanism to pinpoint features of potential concern. The relationship between the structure and performance serve to identify stress points of the system in early stages of design. The earlier the complex modules are identified in a system the lower will be the development and modification costs that would otherwise ripple through the
Acknowledgements
This work was partially supported by National Science Foundation Grants DMI-9908267 and DMI-0075572, and Ben Franklin Technology Partnership through Penn State's Center for Manufacturing Enterprise Integration.
References (28)
- et al.
The evolution of control architectures for automated manufacturing systems
Journal of Manufacturing Systems
(1991) Synthesis of heterarchical manufacturing systems
Computers in Industry
(1990)- et al.
Real-time distributed scheduling of heterarchical manufacturing systems
Journal of Manufacturing Systems
(1994) - et al.
Literature review on software metrics
(1987) - et al.
Evaluating and comparing the software metrics in the software engineering laboratory
ACM Sigmetrics, Performance Evaluation Review
(1981) - et al.
Shop floor control systems: from design to implementation
(1991) - et al.
Applying and assessing two methods for measuring complexity in manufacturing
Journal of the Operational Research Society
(1998) Are current approaches sufficient for measuring software quality?
Proceedings Software Quality Assurance Workshop
(1978)- et al.(1989)
- et al.
Distributed system-level control of vehicles in a high performance material transfer system
IEEE Transactions on Control Systems Technology
(1995)
Elements of software science
Software structure metrics based on information flow
IEEE Transactions on Software Engineering
An object-oriented analysis and design method for shop floor control systems
Computer Integrated Manufacturing
Cited by (24)
A quantitative method for evaluating the complexity of implementing and performing game features in physically-interactive gamified applications
2017, Computers in Human BehaviorCitation Excerpt :This metric is based on the Information Flow metric proposed by Henry and Selig (1990). The Information Flow and other analogous metrics have been extensively used in the software literature to measure the complexity of implementing, maintaining, and/or understanding different applications (Jabangwe, Börstler, Šmite, & Wohlin, 2015; Mens, 2016; Phukan, Kalava, & Prabhu, 2005). The foundation behind Information Flow is that the complexity of an application is a function of (i) the internal complexity of its features (“intra-module complexity”) and (ii) the complexity of the feature interactions (“inter-module complexity”).
DIMENSIONS OF PRODUCT COMPLEXITY FROM DESIGNERS' PERSPECTIVES
2023, Proceedings of the Design SocietyThe impact of system representation choices on architecting insights
2023, Systems EngineeringSo You Think Your System Is Complex?: Why and How Existing Complexity Measures Rarely Agree
2022, Journal of Mechanical DesignMeasuring the Overall Complexity of Graphical and Textual IEC 61131-3 Control Software
2021, IEEE Robotics and Automation LettersComplexity should not be in the eye of the beholder: How representative complexity measures respond to the commonly-held beliefs of the literature
2021, Proceedings of the ASME Design Engineering Technical Conference