Available online at www.sciencedirect.com
ScienceDirect Procedia CIRP 60 (2017) 157 – 162
27th CIRP Design 2017
Model-based Systems Engineering of discrete production lines using SysML: an experience report Johan Van Noten*, Klaas Gadeyne, Maarten Witters Flanders Make, Celestijnenlaan 300, 3001 Heverlee, Belgium * Corresponding author. e-mail address:
[email protected]
Abstract During the design of complex mechatronic systems, multiple engineering teams covering disciplines such as mechanics, electronics, control and safety must cooperate and exchange information. Today’s state-of-the-practice systems engineering methodologies rely on document-based approaches to elicit and manage requirements, describe the system architecture, log design decisions and exchange this information between the project members. Unfortunately, the informal character of the documents causes misinterpretations, generates inconsistencies and prohibits the use of computer power for validation. Model-based Systems Engineering techniques promise to alleviate some of these issues. SysML is a formal graphical modeling language that aims to support this model-based design of complex multidisciplinary systems. Yet, as SysML is a general-purpose language intended to cover a broad range of systems, applying SysML to a specific domain such as production lines is not a trivial task. In this paper, we present some experiences and limitations encountered when applying and tailoring SysML 1.4 to support the systems engineering process of an industrial use case: the design of a production line by a multi-disciplinary team across several companies, consisting of process experts, control engineers, thermal designers, software engineers, mechanical designers, signal processing experts, roboticists and embedded hardware designers. © Published by Elsevier B.V. This 2017The TheAuthors. Authors. Published by Elsevier B.V.is an open access article under the CC BY-NC-ND license ©2017 (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the scientific committee of the 27th CIRP Design Conference. Peer-review under responsibility of the scientific committee of the 27th CIRP Design Conference Keywords: SysML; model-based; discrete production machines;
1. Introduction As products get ever more complex, the production lines capable of producing these become equally complex and hence harder to design. In most companies, the Systems Engineering aspect of the design process is often still organized in a document-based fashion. Based on the trend towards model-based approaches for several parts of the design cycle, companies also consider the possibility to adopt modeling for the Systems Engineering aspects of their design process. SysML [1] is often positioned as the de facto standard language for model-based System Engineering, therefore the advice to those companies might just be formulated as: “adopt SysML”. Yet, several challenges hinder easy adoption of
SysML in the context of Systems Engineering of production lines. First, SysML is a language, and not a methodology. Several tools exist on the market, supporting this SysML language. Some tools are inspired on SysML but enforce their proprietary method or process, e.g. Capella [2]. Other tools are method agnostic, as is the SysML specification itself [3], [4]. When transitioning to a model-based approach based on SysML, companies are often lost... "How should we use SysML?". For each company, the answer is somewhat different, so this paper does not pretend to cover or comment on a universal process. A first objective of this paper is to present SysML specific observations that do not depend on any specific method, but that are observed while using SysML to support the Systems Engineering of production lines.
2212-8271 © 2017 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the scientific committee of the 27th CIRP Design Conference doi:10.1016/j.procir.2017.01.018
158
Johan Van Noten et al. / Procedia CIRP 60 (2017) 157 – 162
Second, SysML 1.4 does not seem to have the language primitives for modeling specific aspects of production lines in a comprehensive manner, without violating the semantics implied by the standard. The paper provides examples and suggests some workarounds. Hence, the second objective of this paper is to elicit these challenges, providing input to be considered by future versions of SysML. The remainder of this paper is organized as follows: Section 2 highlights some related work. Throughout the paper, the example diagrams will be based on the Systems Engineering of a cupcake manufacturing production line introduced in Section 3. Section 4 lists the observed representation difficulties in SysML. The conclusion and ideas for future work are presented in Section 5. 2. Scoping and related work For years, industry has development processes in place, partially company specific, partially based on standards, such as ISO-15288:2015 [5] and Incose [6]. System Modeling language and method extensions such as SysMod [7] and OOSEM [8] are valuable sources of inspiration for many companies. They cover many aspects of the broad Systems Engineering domain. It is therefore important to correctly position the work presented in this paper. The findings proposed in this paper are obtained from industrial projects in which designers from various engineering disciplines were specifically interested in a formal description of the structure and behavior of the production line’s design, and its evolution throughout the design process. As such, the main intent of the model is to foster discussion, and provide clarity and consistency. Therefore, several other Systems Engineering aspects are not described in this paper, such as consistency and reuse [9], design process information [10], requirements and their traceability, analysis methods, validation & verification. These aspects are discussed in broader scoped publications such as [11], [12], [13] and [14] and should be considered as complementary to the formal description of the system under design proposed in this article. The modeler/system architect was a modeling and SysML expert, but the consumers of the modeled information were engineers from various backgrounds: experts in their own domain, but not specialized in model-based architectural representations. Any proposed visualization strategy should
therefore be understandable from their point of view without spending a lot of time in learning a new language syntax and semantics. Finally, this paper considers the Systems Engineering of a set of machines that participate in the production of a discrete workpiece. The term ‘discrete’ is used to exclude continuous production processes such as most chemical ones, but instead considers only those lines in which every single product is a separate workpiece. Summarized: where standards and related work often provide high-level guidelines for the full systems engineering life-cycle, this paper provides more detailed experiences on a smaller part of the systems engineering process and in a smaller application domain: x Only descriptive modeling with a focus on fostering discussion, providing clarity and consistency. x Only in the context of the design of discrete production lines. 3. A case example: a cupcake baking line To avoid exposing confidential information, this paper’s observations are clarified with a fake production line scenario fabricated to reflect the challenges encountered in a real production line: an "advanced" cupcake baking line. This section explains the high-level functionality of this cupcake production line. More details to understand specific issues will be introduced in the relevant sections below. The production line of cupcakes needs to implement several functions, as illustrated in Figure 1: x Paper cups enter the production line and an ID is printed on their bottom. x Next, a dough filling action puts each paper cup in a separate mold and fills it with a suitable amount of dough. This mold is a rather complex element and is therefore depicted in Figure 2: it features heat pipes, temperature sensors and can be covered by a lid. x The filled mold is transported to the baking oven, where the cupcake gets baked and then passes on to a cooling system for a controlled cooling. x Finally, a decoration action applies a variable set of decorations to the cupcake (cream, chocolate chips...).
Figure 1: SysML 1.4 Activity Diagram (similar to a flow chart) explaining the different, high-level steps that need to be performed by the production line under design: a cupcake production line. Green lines denote Material Flow, blue denotes Data Flow and red denotes Energy Flow.
Johan Van Noten et al. / Procedia CIRP 60 (2017) 157 – 162
Figure 2: Pictorial representation of the fictitious baking mold, containing a paper cup, some dough and covered by a lid.
Figure 1 makes abstraction of the precise information flow between the cupcakeSpecification parameter and the blue input pins on the different actions. 4. Experiences of SysML to model production lines SysML is positioned as a language suitable to support model-based Systems Engineering. Indeed, most aspects of the production line could be expressed conveniently using SysML diagrams and some language customizations. On the other hand, it turns out that several aspects of the production line model are difficult to express in SysML. These observed shortcomings are listed in the following sections. 4.1. Representing implicit physical interactions When expressing physical structures that perform physical operations, the expressiveness of SysML's structural diagrams, such as an Internal Block Diagram (IBD), is limited. Engineers complain that the structural diagrams do not show which elements interact if the interaction is not reflected in a Port. Consider the initial steps in the oven’s physical operation: an OpenMold and a PaperCup enter the Oven. The cup is detected using a PresenceDetector and an ItemPusher pushes the cup in the mold once it is detected. For the engineer, it is impossible to derive these implicit interactions from a diagram such as in Figure 3 on the left.
Nowhere it explicitly shows that the detector or the actuator do anything at all with a cup. In SysML, the modeler can define ports and connectors to explicitly represent physical interactions, e.g. the interaction between PresenceDetector and CupcakeOvenController: the first sends a detection signal to the latter. Unfortunately, not all physical interactions can be represented in this explicit way. A SysML structural diagram does not pretend to be able to describe behavior, but it does intend to show which parts of the system interact. SysML lacks a formal concept that shows implicit physical interactions. Although the PresenceDetector can be assigned a Port of type Light, it makes no sense to do the same for a PaperCup. The fact that a PaperCup reflects light is one of its many physical properties and modeling all of these would be impossible nor desirable. A potential workaround is shown in Figure 3 on the right. To partially alleviate the engineers’ complaints, one can draw flows between interacting elements. SysML provides the concept of Flows which have quite unspecified semantics and few restrictions, so it is possible to use them for this purpose, although a formal concept would be preferable. 4.2. Reflecting workpiece state Another aspect is the workpiece's state throughout the model. Changes are applied during the realization of the workpiece and they should be visualized in the model. For instance, in the CupcakeOven, the mold enters “cold, without lid and empty”. It travels through the oven and exits “hot, with lid and having a cup and cake inside”. Some aspects do not matter that much and can be considered as internal state of the object. For instance, hot and cold could be reflected through system states in a separate SysML State Machine diagram, or reflected as a temperature property on the mold Block. Unfortunately, such internal states cannot be reflected in other diagrams such as IBDs. One attempt to augment the clarity towards the model consumer is to reflect the state in the name of the port, e.g. empty Mold or
Figure 3: On the left, the implicit physical interactions are invisible. On the right, these interactions are represented by Flows.
159
160
Johan Van Noten et al. / Procedia CIRP 60 (2017) 157 – 162
Figure 4: Different workpiece states reflected through inheritance.
moldAndCake. Unfortunately, this is merely an informal approach. Other aspects cannot be reflected in this way. The fact that the incoming mold has no lid and the outgoing one does, changes the element structurally. The CupcakeOven needs to type its input port with something that forces no lid to be there, while any system following the CupcakeOven in the production process will have an input port that expects “a mold with a lid”. A valid representation for these structural differences could be achieved using UML’s Generalization as shown in Figure 4, potentially with a {disjoint, complete} GeneralizationSet. The oven’s incoming port could then be typed by OpenMold and the outgoing one by ClosedMold. Unfortunately, this solution violates the UML instance semantics. When the mold passes through the oven, at what place and how should the OpenMold instance suddenly change into an instance of ClosedMold? Moreover, this mechanism could work when there are only a few variants of the Mold type. Often workpieces are more complex than a single variation point only. In this example, although a bit forced, suppose that a mold would have 3 removable lids. Each lid could be present or absent, resulting in 8 different Generalization variants. Till now, no solution is found that combines clarity for the model consumer and yet does not violate the SysML.
For instance, the mold should be represented at different locations in the production line. Arriving in the oven, the first action is to connect the mold’s heat pipes and sensors. At a certain dough-temperature, a lid is put on the mold and the heat pipe and sensor in the lid are connected as well. From that moment on, both the mold and the lid are getting heated and the baking process continues. Before exiting the oven, all heat pipes and sensors are disconnected, but the lid remains on. Additional examples occur further down the production line, were the lid gets removed and the cup and cake are removed from the mold. Building a structural model that clearly describes this behavior is a challenge. SysML structural diagrams do not reflect any behavior. One could use Activity Diagrams for this purpose, but the engineers want to understand what happens by looking at a structural diagram of the oven’s internals only. Since the lid’s presence and the heat pipe connections are varying over time, no single structural picture is correct. Even showing the mold is not always correct, because at some points in time, there is no mold at all in the oven. Requiring the engineers to use the structural IBD together with the behavioral Activity Diagram and “imagine” themselves the impact on the structure is not satisfactory: it is confusing and leads to possible interpretation mistakes. One workaround we used is to create temporal snapshot IBDs. Engineers benefit from multiple slightly different IBDs that reflect the structurally different scenarios. The diagram at
4.3. Modeling complex workpieces traveling through the line A significant part of a model usually describes static information. If one models a car, most modeled elements of the car do not move or (dis)assemble over time. The engine runs, doors can open and close, but that’s it. There are examples of materials entering the car, moving through the car and exiting the car, such as fuel. Often it is not required to describe the fuel in more detail (behavior, state, inputs, outputs). It could merely be used to type some flows. This paper considers production line scenarios, where also most elements are static. Additional detailed modeling is often required though for the workpiece itself or for some machine part that travels together with the workpiece. In the example of the cupcake baking line, the mold containing the cup and the dough is a complex modeled element as can be seen in Figure 2: it contains heat pipes, sensors and a lid that can be present or absent. At first sight, this does not pose any modeling challenges, but there are some non-trivial aspects anyway.
Figure 5: IBDs of the relationship between a heater and the mold before adding a lid (on top) and after adding a lid (bottom). The heater is twice the same element; the molds have a different type.
Johan Van Noten et al. / Procedia CIRP 60 (2017) 157 – 162
the top in Figure 5, shows (a fragment of) the state of the oven just after connecting the mold’s heat pipes and sensors. The bottom one shows a snapshot of the oven when the lid is closed and the additional heat pipes are connected. Unfortunately, the concept of temporal snapshot IBDs has several drawbacks, as detailed below. 4.3.1. Duplicate work Since time-snapshot IBDs are often almost identical, a modeler must perform quite some duplicate work, creating and maintaining these multiple snapshots. A concept of diagram inheritance would help: draw the common diagram, then draw several inherited diagrams, slightly specializing the common one. Unfortunately, the standard does not include such a concept in its diagram interchange specification (UML 2.5, annex B), so tools have no standardized basis to support this. 4.3.2. Violation of UML/SysML specification Considering that both IBDs are representations of the same Block in the model, the heater part has duplicate connectors connected to most of its ports: e.g. heatPipe1 is connected to heatPipeIn1 of a part called openMold (typed by OpenMold) while in the second IBD it is connected to heatPipeIn of a part called closedMold (typed by ClosedMold). Having two parts for one physical object is violating semantic intent. Having the two described connectors is even violating the multiplicity rules, since a heat pipe can only be connected to one destination. 4.4. SysML overrules UML constraints While the previous sections discuss shortcomings in the expressiveness of the SysML language for the context of production lines, the current section discusses a problem with the SysML language’s definition that will be encountered in any context. An important convenience during the creation of a system model is the ability to validate the model. The tool checks whether the modeler’s work complies to the rules of the language. SysML is defined as a language that subsets UML and adds some concepts to it. Consequentially, one expects that any valid SysML model is a valid UML model as well. Unfortunately, the SysML specification authors have decided to relax some of UML’s constraints. Essentially, this means that a SysML model can be valid, even though it is not a valid UML model. Section 4.4 “Extension Mechanisms” of the SysML spec version 1.4 [1] explains the extension mechanisms used by SysML to extend UML. Constraint relaxations are not mentioned in that section. Moreover, the base language UML does not support constraint relaxations as a valid extension mechanism. A clear example of such a constraint relaxation concerns UML's constraint "UML::Connector::role", specified in section 11.8.10.7 of the UML 2.5 specification [15]. This specifies that ConnectorEnds need to point to roles/parts owned by the Connector's structuredClassifier (direct or inherited). The SysML specification for NestedConnectorEnd (8.3.1.2.6, 8.3.2.11) does conflict with that UML constraint, since it relaxes this required ownership.
Figure 6: UML validation causes a warning on SysML’s BindingConnector, while the given connector is perfectly legal from SysML point of view.
Therefore, a modeler can create a compliant SysML model, i.e. using valid SysML constructs, but obtain UML validation errors anyway. As an example, consider the internal block diagram shown in Figure 6. It shows the cake inspection subsystem containing an InspectionSystem instance and a Robot instance. The InspectionSystem needs a Camera instance, but does not own any (indicated by using a reference part). The Robot owns a Camera instance and can “offer” it for use by other systems. This can be modeled in several ways, but one way is specifying the Camera instance as a reference in the InspectionSystem and later binding this instance to the Camera owned by the Robot. In the case of systems with multiple Cameras and multiple Camera users, this visualization conveniently shows which user will employ which Camera. This can be accomplished using a BindingConnector, but UML validation complains about the BindingConnector’s ends violating the constraint mentioned above. The SysML stereotype for the BindingConnector “illegally” relaxes the given constraint on UML connectors. Tooling can be adjusted to suppress the validation in the case of a SysML model. Unfortunately, this just hides the specification conflict. Instead, the specification’s authors should resolve the conflict. The paper’s authors have submitted this issue to the OMG more than a year ago [16], but no activity on the issue has been observed yet. 5. Conclusions and further work As a mature language with readily available tools, SysML is without doubt a valuable instrument supporting the design of complex systems. Unexpectedly, some scenarios trivially occurring in the context of production lines for discrete workpieces, have no obvious solution in SysML 1.4: describing implicit physical interactions, reflecting workpiece state, modeling complex workpieces traveling through the line, avoiding UML validation issues. This paper suggests some workarounds, but the core issues remain unresolved. As stated in the paper’s introduction, a first objective was to draw method agnostic conclusions. While the presented findings were derived from work in a very specific context, the paper makes no assumptions on the use of a specific methodology. The observations are only depending on the expressiveness of SysML as a language, and therefore probably
161
162
Johan Van Noten et al. / Procedia CIRP 60 (2017) 157 – 162
[2] P. ROQUES, “MBSE with the ARCADIA Method and the Capella Tool,” in Proceedings of 8th embedded real-time software and systems ERTS2 2016, Toulouse, 2016. [3] No Magic, “MagicDraw,” [Online]. Available: http://www.nomagic.com/products/magicdraw.html. [Accessed 31 10 2016]. [4] Eclipse, “Papyrus,” [Online]. Available: http://www.eclipse.org/papyrus/. [Accessed 31 10 2016].
Figure 7: Example of a SysML tool extension that allows to visualize design issues directly annotated to the graphical model.
applicable to the Systems Engineering of other mechatronic and cyber-physical systems as well. As such, the described limitations can be considered as useful input for future versions of SysML, as set forth by the paper’s second objective. Supplying language elements that can cope with the presented scenarios, would improve the SysML language in two ways: the usability for the modeler and the clarity towards the domain expert who is typically not a SysML expert. Nevertheless, based on their experiences, the authors are convinced that, already today, many companies can realize a significant benefit by adopting model-based techniques to support their Systems Engineering process, when compared to their current document-based approaches. Several elements slow this desired adoption down: the mentioned challenges, the intrinsic complexity of the SysML language and the difficulty to devise a suitable methodology supported by an optimally aligned tool (or customization). The authors focus their future work on closing this valley of death [17]. Also towards the standards bodies, the authors will keep suggesting improvements. The foremost part of the future work focuses on the pragmatic needs of the System Engineer who should be able to realize systems without the need to be an expert on all aspects of the SysML language. A pragmatic reduction of the tooling towards specific domains is an open work topic. On the other hand, additional usability features beyond default SysML are required as well to enhance the value of the model-based approach. One such example is the tracking of design issues inside the model. Figure 7 shows an example of a tooling extension where the CupPrinter is automatically colored red and validation warnings pop up, drawing the System Engineers attention to a pending issue. In summary, Systems Engineering remains a difficult task which involves quite some expertise from multiple domains. Based on their experiences, the authors do believe that the Systems Engineer would benefit from enhancing the SysML language’s expressiveness, tailoring its complexity towards the System’s domain and adding corresponding tool automations.
References [1] Object Management Group, “OMG Systems Modeling Language™ (SysML®), Version 1.4,” 03 06 2015. [Online]. Available: http://www.omg.org/spec/SysML/1.4/PDF.
[5] International Organization for Standardization, "ISO/IEC/IEEE 15288:2015 Systems and software engineering -- System life cycle processes," 15 05 2015. [Online]. Available: http://www.iso.org/iso/catalogue_detail?csnumber=63711. [6] Incose, Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4th Edition, INCOSE, 2015. [7] T. Weilkiens, SYSMOD - The Systems Modeling Toolbox, MBSE4U Tim Weilkiens, 2015. [8] Incose, "INCOSE Object-Oriented Systems Engineering Method (OOSEM)," 25 04 2011. [Online]. Available: http://www.omgwiki.org/MBSE/doku.php?id=mbse:incoseoosem. [Accessed 31 10 2016]. [9] K. Woestenenk, “Consistency, integration, and reuse in multidisciplinary design processes,” University of Twente, Enschede, the Netherlands, 2014. [10] K. Woestenenk, G. M. Bonnema, A. A. Alvarez Cabrera and T. Tomiyama, “Capturing design process information in complex product development,” in ASME IDETC/CIE, Washington, DC, USA, 2011. [11] L. Bassi, C. Secchi, M. Bonfe and C. Fantuzzi, "A SysML-Based Methodology for Manufacturing Machinery Modeling and Design," in IEEE/ASME Transactions on Mechatronics, 2011. [12] E. Mancin, "How Model Based Systems Engineering streamlines the development of complex systems," in INCOSE Italian Chapter Conference on Systems Engineering, Rome, Italy, 2014. [13] V.-H. B. Kernschmidt K, “An interdisciplinary SysML based modeling approach for analyzing change influences in production plants to support the engineering.,” in IEEE Int Conf Autom Sci Eng., Madison, US-WI, 2013. [14] S. Feldman, "Combining a SysML-based Modeling Approach and Semantic Technologies for Analyzing Change Influences in Manufacturing Plant Models," in Variety Management in Manufacturing – Proceedings of the 47th CIRP Conference on Manufacturing Systems, 2014. [15] OMG, “Unified Modeling Language (UML) Version 2.5,” 01 03 2015. [Online]. Available: http://www.omg.org/spec/UML/2.5/PDF. [Accessed 04 01 2017]. [16] J. Van Noten, “OMG Issue 19813,” 30 6 2015. [Online]. Available: http://www.omg.org/issues/issue19813.txt. [Accessed 04 01 2017]. [17] J. Hudson and H. F. Khazragui, “Into the valley of death: research to innovation,” Elsevier, 2013.
