ISE Magazine Volume: 49; Number: 10
By Timothy Sprock and Leon F. McGinnis
Today, industrial engineers work in many large, complex cyber-physical systems, such as semiconductor device manufacturing, aircraft production, global supply chains and healthcare delivery. IEs develop many kinds of analysis models in these application domains. The factor limiting the contribution or impact of IEs is not our analytical methods or computational tools. Rather, it is our ability to deal with complex interactions among a multitude of stakeholders and decision-makers, interactions that are difficult or impossible to capture in single-dimension analysis models. The institute’s recent name change, adding “systems” to become the Institute of Industrial and Systems Engineers, reflects the evolution of IE to industrial and systems engineering (ISE).
Domain-specific reference models
ISEs are experienced in using modeling tools, from databases to spreadsheets to simulation to optimization. That experience teaches us that it is very easy to use powerful modeling tools to create ad hoc models that are difficult to maintain or reuse. How can ISE practitioners avoid that problem in creating system models?
The SE experience of MBSE teaches us that it is essential to first develop a way of thinking and talking about the system domain of interest – now being referred to as “reference model.” Reference models provide the semantics and syntax for describing large classes of systems in the domain of interest and are used as a starting point for developing models of individual systems. In modern interoperable computing environments, these models incorporate many viewpoints, including descriptions of the hardware, control software, information technology systems – possibly even analysis models that provide decision support. Reference models supporting these viewpoints may be captured as libraries of validated, reusable model components and patterns for assembling them into meaningful systems, enabling system modelers to produce consistent results.
Separate reference models should be created for major subdomains of ISE, such as warehouses, transportation systems, manufacturing plants, supply chains and hospitals and healthcare delivery systems. For example, a reference model for warehousing would include detailed descriptions of the classes of objects in the systems, such as products (e.g., SKUs, pallets, cases, etc.), processes (e.g., pick, sort, pack), resources (operators, lift trucks, floor space, etc.) and facilities (departments, layouts, etc.). These classes can be combined to create reusable subsystem models, such as automated storage and retrieval systems or conveyor systems. These definitions address not only the class properties, but also interfaces, so that models can be checked to ensure valid connections between classes.
Domain-specific reference models also enable the development of complementary standard “testbeds.” There are interesting questions that cannot be explored today because of the cost to develop high-fidelity simulation testbeds. These analysis models are time-consuming to develop, share and maintain using contemporary approaches. However, MBISE methods could make it possible to describe a system and its operating conditions and then automate the generation of the simulation testbed, complete with controllers that use standard interfaces for decision support. In this scenario, prospective researchers could focus on developing and benchmarking decision support methods, rather than developing the testbed itself.
Domain-specific design methodologies
Reference models for ISE-specific domains of practice are a critical first step. To apply reference models in a consistent, repeatable manner, there needs to be a corresponding system design methodology addressing the complete system life cycle. In the SE discipline, the methodology has several clearly identified phases: articulating stakeholder needs, identifying system requirements, developing logical system architectures, detailed subsystem design, implementation, integration, testing, validation and verification, and deployment. For each phase, there is a robust literature discussing methods, tools and practices.
Warehousing is an important domain of ISE research and practice. Warehouses can be argued to be simpler and easier to understand than, say, aircraft assembly, semiconductor manufacturing or global supply chains. Yet if one examines the ISE literature on warehousing or the textbooks that address warehousing, one will not find the kind of detailed, step-by-step design methodology that is common in other engineering disciplines. In fact, ISE research and teaching tends to approach design as an exercise in generating and evaluating alternatives, without much guidance for how those alternatives are generated. Adopting domain-specific design methodologies could facilitate a rich environment for exploring the theory of decision-making for multiple decision-makers across multiple system disciplines. MBISE will be most successful if a more rigorous approach to design is taken, and this represents a challenge to both our research and teaching missions.
Integrated analysis tools
A major benefit of MBISE approaches would be providing system modelers and designers with “push button” access to analysis models. In model-based system-analysis integration methods, decision support analysis models are derived, transformed or otherwise automatically generated from the analysis-agnostic system model. Multiple types of analysis models can be constructed from the same description of the system. Formulating routine analysis models to answer standard questions will no longer be an art practiced by the system modeler or designer, but rather a repeatable, deterministic activity with predictable outcome: high-quality, verifiable answers to those routine questions.
This runs counter to the traditions of ISE (and operations research), which emphasizes building analysis models. However, if we have useful reference models and common design methodology, then we can identify “standard” questions that can be answered with “standard” analyses. As an example, suppose the question is, “How should a pallet rack system be configured in terms of tier height, number and length of aisles to achieve a particular storage capacity?” We know how to answer this question, and developing a standard solution is possible, provided we have standard information models.
As ISE domain-specific tools for system design, planning and control become available and prove the value of standardized descriptions, we may see systems-related specializations within the discipline. For example, ISE systems designers may need to know which tools to use and when, while ISE systems analyzers may be the providers of specialized decision support. In the SE space, MBSE innovations have been driven by practitioners, often in collaboration with researchers. This is a good model for the ISE community. Without usable domain-specific tools, MBSE would have remained a concept and not a practice.
Published at :