Complexity metrics for manufacturing control architectures based on software and information flow

https://doi.org/10.1016/j.cie.2005.01.005Get rights and content

Abstract

A number of architectures can be used to integrate different components of a manufacturing enterprise such as machine tools, robots, and guided vehicles. The choice of architecture has a significant impact on system complexity, which in turn determines properties such as scalability, flexibility, fault-tolerance and modifiability. There is a need to develop metrics that quantify the complexity of a system that can serve as a means for comparing alternative architecture at the design stage. In this paper, we propose metrics used in software engineering to characterize the complexity of manufacturing systems. These metrics have been applied for measuring the complexity of two software systems: material delivery system and distributed scheduling.

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):Complexity=IntraModuleComplexity(InterModuleComplexity)2

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)

  • D.M. Dilts et al.

    The evolution of control architectures for automated manufacturing systems

    Journal of Manufacturing Systems

    (1991)
  • N.A. Duffie

    Synthesis of heterarchical manufacturing systems

    Computers in Industry

    (1990)
  • N.A. Duffie et al.

    Real-time distributed scheduling of heterarchical manufacturing systems

    Journal of Manufacturing Systems

    (1994)
  • R. Adamov et al.

    Literature review on software metrics

    (1987)
  • V.R. Basili et al.

    Evaluating and comparing the software metrics in the software engineering laboratory

    ACM Sigmetrics, Performance Evaluation Review

    (1981)
  • A. Bauer et al.

    Shop floor control systems: from design to implementation

    (1991)
  • J. Bermejo et al.

    Applying and assessing two methods for measuring complexity in manufacturing

    Journal of the Operational Research Society

    (1998)
  • J.B. Bowen

    Are current approaches sufficient for measuring software quality?

    Proceedings Software Quality Assurance Workshop

    (1978)
  • Dreger et al.
    (1989)
  • N.A. Duffie et al.

    Distributed system-level control of vehicles in a high performance material transfer system

    IEEE Transactions on Control Systems Technology

    (1995)
  • M.H. Halstead

    Elements of software science

    (1977)
  • S. Henry et al.

    Software structure metrics based on information flow

    IEEE Transactions on Software Engineering

    (1981)
  • IFPUG, Function Point Counting Practices Manual: Release 3.4 (1992). International Function Point User's...
  • C.-M. Liu et al.

    An object-oriented analysis and design method for shop floor control systems

    Computer Integrated Manufacturing

    (1998)
  • 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 Behavior
      Citation 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”).

    View all citing articles on Scopus
    View full text