2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany “©2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.”
Using UML in Control and Automation: A Model Driven Approach Kleanthis C. Thramboulidis Electrical & Computer Engineering, University of Patras, 26500 Patras, Greece, e-mail:
[email protected]
ment of complex control systems. Heck et al. give in [2] a tutorial overview of specific new software technologies that are useful for the implementation of complex control systems and claim that component based architectures, and the object-oriented approach are technologies very promising for the control and automation application domain. ObjectTechnology has attracted the interest of researchers in control and automation from the early 90’s. In this paper, we examine the use of the Unified Modeling Language (UML) [4], which is the new industry standard for object-oriented development, in the control and automation domain. We discriminate and briefly describe three approaches that dominate the DCS domain. We have adopted, in the context of the CORFU project, the so called “hybrid approach”. This approach integrates UML with the already well accepted by control engineers FB construct, to cover the analysis and design phases of the development process. A model driven approach is followed to move from analysis through design, to implementation. IBM’s Rational Rose is utilized to cover the analysis and early design phases. CORFU FBDK is used to automate the transformation of the so created UML models to FB design models. These design models are next translated to executable models following a fully automated model-to-model transformation process. Two alternatives for the implementation model are considered and briefly described. The applicability of the UML profile for Schedulability, Performance and Time (SP&T) [5] to the proposed development process, is also examined. A simplified control system, the Teabag Boxing Control System (TBCS), is used as a running example throughout the paper. The remainder of this paper is organized as follows: In the next section, we refer to UML, as a notation to model software systems and we briefly present a historical perspective that exploits the power of this new industry standard. In section 3, we discriminate and briefly describe three possible scenarios for the development of today’s DCSs. Our model driven approach is described in section 4. In section 5, the applicability of the UML profile for SP&T is examined. Finally, we conclude the paper in the last section.
Abstract—The Function Block (FB) has been defined by the International Electro-technical Commission as the basic construct for the development of reusable, interoperable, distributed control applications. However, the FB does not exploits recent advances in software engineering. The Unified Modeling Language (UML) is the new industry standard for modeling software-intensive systems. UML brings in the development process the best software engineering practices. In this paper, we examine the use of UML in control and automation and describe the use of a hybrid approach in the development process of distributed control systems. The proposed approach integrates UML with the already well accepted by control engineers FB construct, to cover the analysis and design phases of the development process. A model driven approach is adopted to move from analysis through design, to implementation. The applicability of the UML profile for Schedulabity, Performance and Time, to the proposed development process, is also examined. Index Terms— Control and automation, Distributed Control Systems, UML, Function Block, model driven development, UML profile.
I. INTRODUCTION The majority of today’s Distributed Control Systems (DCSs) consist of industrial-grade computers or PLCs, which are interconnected by dedicated fieldbus networks. Control applications are usually developed in the form of large monolithic software packages that are difficult to maintain, modify, and extend [1]. The market is dominated by a small number of very large corporations with proprietary solutions and the engineering tools used in the development and deployment processes address a little, or not at all, dimensions such as modularity, flexibility, extensibility, reusability, and interoperability. Even one of the most common design and analysis tools for control systems, the family of MATLAB products, tends to generate monolithic rather than component based C language code, which makes the validation and code update more difficult as reported by Heck et al. in [2]. The International Electro-technical Commission (IEC), in an attempt to define an open standard for DCSs, has defined the basic concepts and a methodology for the design of modular and re-usable systems. The IEC61499 standard [3] defines the Function Block (FB) as the main building block and the way that FBs can be used to define robust, reusable software components that constitute complex DCSs. However, the FB approach does not incorporate current practices of software engineering. Advances in software technologies may facilitate the development and deploy-
II. UML: A MODELING NOTATION A . Modeling of software systems Modeling, which is as old as engineering, is the designing of software applications before coding. It is an essential part of large software projects, and helpful to medium and even small projects as well [6]. A large number of methods
1
2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany have been proposed, in the last years, to support the creation of models for software systems. Until 1989 the proposed methods followed the structured approach with the structured analysis and structured design (SA/SD), created by Yourdon and Constantine in 1987, to be considered the most widely used method. An updated version of this method, called Modern Structured Analysis, was published in 1989 by Yourdon. However, this method did not attain wide acceptance since: a) the complexity of today’s systems is almost impossible to be handled by the traditional procedural-like approaches, and b) many new proposals, following the more promising object-oriented (OO) approach, appeared at the same time. The great advantage of the OO paradigm, which has been gradually accepted during the last decade, is the conceptual continuity across all phases of the software development process [7]. In the 90’s, at least 20 object-oriented methods have been proposed in books and many more have been proposed in conference and journal papers. A survey and a classification scheme for object-oriented methodologies can be found in [7]. In the same article, the author states that, “after more than thirty years since the first OO programming language was introduced, the debate over the claimed benefits of the object-oriented paradigm still goes on. But there is no doubt that most new software systems will be objectoriented; that no-body disputes.” Wieringa surveyed, in [8], state-of-the-art structured and object-oriented development methods. He identifies the underlying composition of structured and object-oriented software specifications and investigates in which respect OO specifications differ essentially from structured ones. The last specification method in his catalogue of OO methods is the Unified Modeling Language version 1.0. UML is the new industry standard for modeling software-intensive systems. UML was conceived as a generalpurpose language for modeling object-oriented software applications. The language represents a further abstraction step away from the one provided by high level programming languages, which are close to the underlying implementation technology. The easiest answer to the question “what is UML?” is, according to Quatrani [9], the following: “UML is the standard language for specifying, visualizing, constructing, and documenting all the artifacts of a software system.”
odyssey of UML is in evolution. Kobryn in [14] placed the end of this odyssey to 2001 but UML 2.0 had a long way to go. Crawford in [15] notes that “proposals of the UML2 are now under consideration, and what’s clear is the future is unclear.” As Miller in [16] argues, UML1 unified several of the competing schools of modeling; however some equally important ideas for good OO design did not influence the language. Further more, a lot of problems have been cited as for example by Kobryn in [14] and [17], and by Dori in [18]. These errors are waiting for a solution in UML2. A spirited debate on the future of UML is in evolution. Five groups submitted proposals in response to the OMG RFPs but hopefully there is a desire for a consensus version as reported by Miller in [19]. They all agree, as reported by Miller and Mukerji in [20], that UML2 should be in the context of OMG’s Model Driven Architecture (MDA) initiative, which considers as primary artifacts of software development not programs, but models created by modeling languages. Artifacts of the Unified Modeling Language should be used to create the platform independent model, which should then be mapped by a model compiler into a platform-specific model, as Mellor states in [21]. The large number of practitioners and researchers that have adopted UML at a rate exceeding even OMG’s most optimistic predictions is a strong argument for UML ver. 2 to follow an evolutionary rather than revolutionary approach. However, as Selic et al. state in [22], “the same forces have also created a strong pressure to improve the effectiveness of UML and provide it with a multitude of new features.” The one thing that is accepted by all parties is that the language’s popularity has confirmed the urgency for a standard communication medium for humans and software tools. It is already widely accepted that UML2 will drive the software development industry for the next decades. UML is methodology-independent, which means that UML can be used as a notation to represent the deliverables defined by the methodology regardless of the type of methodology used to perform the system’s development, i.e. whether it is rigorous such as the Unified Process that is defined by Jacobson et al. in [23], or lightweight such as the Extreme Programming that is defined by Paulk in [24]. In any case, the methodology will guide the engineer in deciding what artifacts to produce, what activities and what workers to use to create and manage them, and how to use those artifacts to measure and control the project as a whole as is reported by Booch et al. in [25]. The twelve diagram types that can be used to model every aspect of the system make UML extremely expressive, allowing multiple aspects of a system to be modeled at the same time. However, this expressiveness comes at a price. UML is extremely large with many notational possibilities as claimed by LeBlanc and Stiller in [26]. Thramboulidis in [27] presents a subset of the UML that represents the core of the language. The presented subset will allow the control engineer to understand the basic concepts of the language and communicate through UML diagrams, the knowledge of the DCS that is under development. Last years there is a trend to use UML in control, industrial automation, as well as in industrial enterprise integra-
B . UML: A historical perspective The UML started out as a collaboration among three outstanding methodologists: Grady Booch, Ivar Jacobson and James Rumbaugh. At a first step Booch and Rumbaugh collaborated to combine the best features of their individual object-oriented analysis and design methods reported in [10] and [11] correspondingly and they presented at OOPSLA in 1995, the Unified Method version 0.8. At that time, the Unified Method was both a language and a process. Later, Jacobson joined the group and contributed the best features of the OOSE methodology that is presented in [12]. The result of this collaboration was the separation of the language from the process, which was later described in [13]. The language was defined and was presented in 1996 as UML 0.9. Later, in January 1997 they submitted their initial proposal as UML 1.0. Since then the standardization
2
2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany tion. A lot of papers present examples of using the UML in many different levels of manufacturing information systems. However, there is a wide gap between the state-ofthe-art in software engineering and the state of practice in industrial applications.
the reference architecture defined in IEC61499. Also the Profinet Engineering Model, which is the proposal of the Profibus User Organization to achieve open distributed automation, even though non IEC-compliant, is planned to have an IEC-compliant mapping in the near future. The big advantage of this approach is that it exploits the experience of industry’s practitioners and easily integrates the big number of existing legacy applications and systems. However, it does not exploit all the benefits of object and component technologies.
III. CONTROL AND AUTOMATION SOFTWARE DEVELOPMENT: POSSIBLE SCENARIOS In this section we try to address the following question “So, what is the future in control and automation software development?”. We discriminate three possible directions: • UML-based approaches, • Function Block-based approach, and • Hybrid approaches integrating UML with the Function Block concept. We next make a brief reference to these approaches.
C. The Hybrid approach This approach integrates the UML notation with the function block concept. However, this integration is done from different perspectives. Brennan et al. in [40] describe two approaches for modeling decentralized Manufacturing Systems with UML capsules. They propose the modeling of the control system at the conceptual level using UML-RT [41] and then they propose a mapping of UML-RT to IEC 61499 models that are used for the implementation of control application. However, a) the described model is not implementable (at least with the information given in the paper), b) no evidence for a reference implementation is given, and c) it is quite difficult for control engineers to model in UML-RT. The approach presented by Thramboulidis in [42], and Thramboulidis and Tranoris in [39] and [43], considers the use of the UML notation in the requirements specification phase using the concept of use case. The UML analysis models are next transformed to FB based models, applying a set of well-defined mapping rules. A specific tool, the CORFU model transformer, automates this process. In this paper, we adopt a model driven development process and describe the process of moving from FB-design models to implementation models.
A. UML-based approaches According to this approach the standard UML notation is used to produce the models of the control system. This is the approach proposed by many researchers such as Douglas in [28], Gomma in [29], Young et al. in [30], and Mosemann and Wahl in [31]. The system is represented using multiple models. Each model describes the system from a distinctly different perspective. Three kinds of views are defined at the top level [33]. The structural classification view considers the things of the system and their relationships with each other. Class diagrams are used to express the static view of the system, use case diagrams to express the use case view, and component and deployment diagrams to express the implementation view. The dynamic behavior view describes the different aspects of the application’s dynamic behavior. Statechart diagrams are used to express the state machine view; activity diagrams to express the activity view; sequence and collaboration diagrams to express the interaction view of the system. The model management view describes the organization of the system models into hierarchical units. Class diagrams are used to express the organization of the system models into hierarchical units. The big disadvantage of this approach is that it is a completely new approach for practitioners in control and automation, which are mainly accustomed with IEC languages and concepts.
IV. A MODEL DRIVEN APPROACH The Model Driven Architecture (MDA) [47], which is consistent with the MIC paradigm firstly presented by Sztipanovits et al. in [44], is an initiative that considers as primary artifacts of software development not programs, but models created by modeling languages. Artifacts of the UML are used to create the platform independent model, which then is mapped by a model compiler into a platformspecific model. In this way the development process is defined as a transformation of models, which constitute instances of meta-models that are defined by domain experts. To illustrate the proposed approach we are using as running example our Teabag Boxing system (TBS) case study. TBS is a simplified version of a real system used in the production chain of packed teabags. The system receives teabags from a teabag producer, checks their weight and forwards them either for packaging to a valid-teabag consumer, or for recycling to an invalid-teabag consumer. TBS is composed of: a) a scale, for weighing teabags, b) a feeder, for rejecting out-of-range teabags, and c) 3 conveyor belts for moving teabags. Figure 1 presents the environment model of the Teabag Boxing System (TBS) and its main components: a) the TBCS that is the controlling system, and b) the Teabag
B. Function Block-based approach This approach, which is the one proposed by the evolving IEC standards 61499 and 61804 [34], is based on the function block construct. Although many researchers are already working on different aspects of the IEC proposal as for example Vyatkin and Hanisch [35], Brennan and Norrie [36], Fletcher and Norrie [37], Thramboulidis and Tranoris [38], the absence of tools and products that are compliant with this approach is evident. The Function Block Development Kit (FBDK) by Rockwell Automation and the CORFU-FBDK [39] are the only known tools supporting this approach. However, it should be mentioned that the IDA architecture, which is proposed by the IDA group (http://www.idagroup.org), proposes an application model that is based on
3
2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany Boxing Mechanical Process (TBMP) that is the controlled system. Sensors and actuators are embedded in the Teabag Boxing Mechanical Process. We consider the development of the mechanical process, namely the TBMP, to be carried out independently of the development process of the controlling system. A more promising approach based on model integration is proposed in [32]. This approach is the first step to what we call Model Integrated Mechatronics. Figure 2 presents an abstract model of the Teabag Boxing Mechanical Process with the appropriate primary sensors and actuators.
analysis domain metamodel. However, the proper stereotypes should be embedded as primitive constructs in the CASE tool. Use cases are used as a means to capture requirements. Table I presents the list of use cases for the TBS. For each use case an initiating Industrial Process Terminator (IPT) is defined which is either the Operator or an entity of the mechanical process. Table I : Use cases for the TBCS Use case title Initiating IPT 1 2 3 4 5 6 7 8 9
Use case: Carry Teabag to conveyor-1 belt-2 Initiating IPT: Conveyor-1 belt-1 IPP: Teabag leaving Conveyor-1 Belt-1 (S4) Involved IPTs: Conveyor-1 Belt-1 M3 (out), Conveyor-1Belt-2 M2 (out) Precondition: Conveyor1-Belt-1 is in the MOVING state. Description The Conveyor-1 Belt-1 notifies the system (through S4) that the Teabag has been moved on conveyor-1 belt-2. The system decrements the internal representation of the number of teabags on conveyor-1 belt-1. If the number of teabags is zero it sends a STOP message to conveyor-1 belt-1 (M3). The system checks the number of teabags on conveyor-1 belt-2 (internal representation). If the number of teabags is zero it sends a MOVE FORWARD message to conveyor-1 belt-2 (M2) and increments the number. The use case is terminated. Postcondition: Conveyor-1 belt-2 is in the MOVING state. Exceptions: [tbd]
Fig. 2. Abstract model of the Teabag Boxing Mechanical Process.
A. Applying the Model Driven Approach Domain specific model interpreters are used by CORFU FBDK to transform the more-PIM, to more-PSM with the objective to obtain a fully automated production of the implementation model. CORFU FBDK fully exploits the IEC61499 function block concept and the UML notation, as well as current practices in distributed real-time software. Domain mapping rules are used to describe the mapping of the source-domain metamodel constructs to targetdomain metamodel constructs. Figure 3 illustrates the model driven approach adopted for the transformation of UML analysis models to FB design models. Domain mapping rules
For the use case realization, we use Component Interaction Diagrams (CIDs) of two levels of abstraction: a) the first-level CID, which captures the interactions of the control application represented as a component, with external entities, and b) the second-level CID (detailed-CID), in which the components required to compose the system for the described behavior to be obtained, should be identified and their collaboration should be defined. Figure 4 presents the detailed CID of the “Carry Teabag to conveyor-1 belt2”. This CID is considered as the first formal realization of this use case. Components of type IPT stereotype and FB stereotype are used to create the component collaboration required for the system to implement the described use case. The CORFU model-to-model transformer that has been implemented as part of the CORFU FBDK, automatically translates the UML analysis model, to FB-based design
Design Domain Metamodel
implements UMLbased Model
CORFU Model Transformer
Operator Operator Scale (S0) Feeder (S1) Scale (S6) Conveyer1 (S4) Conveyer1 (S3) Conveyer2 (S5) Feeder (S2)
We next give the “Carry Teabag to conveyor-1 belt-2” use case to demonstrate our slightly modified notation for use cases to capture the semantics of control applications.
Fig. 1. The Teabag Boxing System
Analysis Domain Metamodel
Initialize TBS Stop system Weight teabag Cary teabag on conveyer-2 Cary teabag on conveyer-1 belt-1 Cary teabag on conveyer-1 belt-2 Valid-teabag finished processing Teabag recycled Feeder Arm Reaches Initial Position
FB-based Model
Fig. 3. The model based transformation process.
The control engineer using a CASE tool, such as the IBM’s RT Rose, defines, in terms of UML, the requirements model of the control application as an instance of our
4
2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany model. Timing constraints that have already been expressed in the form of end-to-end response time in CID diagrams, should be spitted to the corresponding FB computational path and result to: a) FB execution constraints that constrains FB Execution Time (FBET), and b) message transfer constraints that constraint message propagation. FBET is the amount of time the FB needs to finish its reaction, provided that it is not preempted by another FB. It represents the actual time spent on FB’s execution. FBET is used to determine schedulability and resource utilization. The timing constraints are attached to messages and include deadline or priority constraint. These constraints should be annotated on the model to make the automated software synthesis process more effective. The annotated model is further refined and converted to a more platform specific model ready to be used for the production of the implementation model. For the transformation of the design model to executable code we are briefly describing the following two approaches: 1. Model transformation to C++ code, and 2. Model transformation to UML-RT models.
A prototype model transformer for C++ code was developed by P.Manesis and is described in detail in [46]. B. Using UML-RT in the model transformation process To obtain a more flexible code generation process than the one described above, we considered the use of UMLRT. Modeling constructs of IEC61499 have quite similar semantics with UML-RT constructs. This enables the transformation of FB design diagrams to equivalent UML-RT design diagrams. The most important task for this transformation is the definition of the FB transformation. We next describe the FBCapsule capsule, which has been defined to represent the semantics of the IEC61499 active basic FB. Classes may be used to represent passive FBs to improve the efficiency of the system, but this mapping is still under investigation. The class diagram of Figure 7 shows the composition structure of the FBCapsule, which we utilize as a template for the transformation of application network’s FBs to capsules of the resulting implementation model defined in terms of UML-RT constructs. //states definition //events definition class { : void OnEvent(Event event); private: void Execute(Event event); bool ChangeState(void); void SetInputEventVariables(Event event); void ResetEventInputVariables(void); void ResetEventOutputVariables(void); : }; Fig. 5. Part of the header file used as pattern in the C++ code generation process.
Fig. 4. A sample CID for the Teabag Boxing Control system.
#include "StdAfx.h" #include "fb6type.h" #include "afxwin.h" ::(void) {}//Constructor ::~< fb name >(void){} //Destructor void ::OnEvent(Event event){ Execute(event);} void ::Execute(Event event){ SetInputEventVariables(event); : while(ChangeState()==true){ switch(current_state){ : } ResetEventInputVariables(); } ResetEventInputVariables(); ResetEventOutputVariables(); } void ::SetInputEventVariables(Event event){ switch(event){ : } } bool ::ChangeState(void){ bool transmission_done=0; switch(current_state){ :} return transmission_done; } void ::ResetEventInputVariables(void){} void ::ResetEventOutputVariables(void){}
Two alternative abstract implementation meta-models independent of run time platform are presented and described in detail by Thramboulidis et al. in [45]. B. FB design model to C++/Java implementation model The XML representation of FB design diagrams is parsed and it is automatically translated to C++ or Java source code. For each FB type a C++ header and a C++ .cpp file is created. The header file contains: a) definitions for states, b) definitions for events, and c) a class corresponding to the FB type. Active FBs are mapped to Java threads or native threads in case of C++ code. A template has been defined for the generated header file, as well for the .cpp file, for the transformation process to be fully automated. Figure 5 presents part of the header template and figure 6 part of the .cpp template. The execute() and changeState() methods are used to implement the FB’s ECC. For the definition of the body of the execute() method the following pattern is used. [for each fb state append] case __STATE: [for each algorithm of state append] this->; .Set; .OnEvent(_ _EVENT); break;
Fig. 6. Part of the .cpp file used as pattern in the C++ code generation process.
5
2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany Figure 8 shows FBCapsule’s structural containment and its communication relationships. We have mapped: a) the input and output events of the FB to the EventPort port, b) the input and output data of the FB to the DataPort port, c) the internal data and events of the FB to corresponding classes, d) the algorithms of the FB to operations of the FBBody class, and d) the head of the FB to the FBHead subcapsule. We have also adopted a port for the configuration of the resulting capsule. The resulting UML-RT model is translated to executable model for a number of platforms using the automatic code generation feature of RT Rose.
niques from the real-time software domain since it captures the common elements of different real-time specific model analysis methods and the essential patterns that are used in deriving time based analysis models from application models. The ESS, adopting the concept of the quality of service (QoS) through this profile, will allow the control engineer to attach quantitative information to FB models in a uniform basis. QoS information annotated on the FB model should represent, directly or indirectly, the physical properties of the hardware and software environments of the system that are represented by the application and system layer models as defined by the 4 layer CORFU architecture[39]. More specifically, the UML profile for SP&T by adding to FB models specific annotations about required QoS, should allow the new generation ESSs to: a) support the analysis of FB models in the early development phases to make predictions on these characteristics and detect problems that can be removed at a much lower cost and with less rework, and b) to support the deployment process of FB applications considering the required by the application and the offered by the system layer QoSs. Specific annotations on the FB model should allow a wide variety of schedulability techniques to be applied. The schedulability model of the system should allow the control engineer to determine whether or not a model is schedulable i.e. it will be able to meet its guaranteed response times. The ESS should allow the engineer to calculate the schedulability of the systems i.e. its ability to meet all of the deadlines defined in the design space, as well as to assist with determining how the system can be improved, as for example suggesting for making an entity schedulable or optimizing system usage for a more balanced system. The big advantage of utilizing this profile is that control engineers should be able to construct models of their DCSs and utilize the different type of model analysis techniques in order to determine whether these models meet their performance and schedulability requirements, without requiring a deep understanding of the inner working of those techniques. However, even though this approach is characterized by its flexibility and powerfulness, it may be proved to be a balk towards the profile’s wide adoption especially until proper tools will appear in the market.
Fig. 7. Composition structure of the FB capsule template
Fig. 8. Structural containment and communication relationships of FBCapsule.
A detailed description of this approach is given in [45]. A prototype implementation for the TBCS has been developed using IBM’s RT Rose to demonstrate the applicability of the approach.
VI. CONCLUSIONS In this paper we have examined the use of the UML in the development process of DCSs. We adopted a hybrid approach that integrates UML with the FB construct and we described our model driven approach that can lead the engineers through a model transformation process from the UML use case requirements models to FB-design models and then to the implementation model through the use of UML-RT. The proposed model driven approach enables us to fully exploit available distributed real-time software technologies such as real-time Java, real-time Linux, realtime CORBA, real-time UML and XML in the domain of DCSs. The exploitation of these technologies for the implementation of the IEC-compliant CORFU system platform greatly enhances the development cycle of DCSs. The UML profile for Schedulability, Performance and Time, may be exploited to improve the development proc-
V. UTILIZING THE UML PROFILE FOR SCHEDULABILITY PERFORMANCE AND TIME The UML profile for SP&T Specification is an attempt of OMG to add in the standard UML notation, lacking quantifiable notions of time and resource that will allow the use of UML in the real-time and embedded domain. The profile utilizes the lightweight extensibility mechanisms of UML to model resource and time-related aspects that constitute the key characteristics of timeliness, performance and schedulability. The created framework is general enough to be adopted and specialized by the FB-based approach in the development of DCSs. It will allow the next generation ESSs to support many different analysis tech-
6
2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany [23] I. Jacobson, G, Booch, J. Rumbaugh, “The Unified Process”, IEEE Software, Vol. 16, No. 3, May/June 1999. [24] N.C. Paulk, “Extreme programming from a CMM perspective”, IEEE Software, Vol. 18 No 6 , Nov.-Dec. 2001. [25] G. Booch, Rumbaugh, J., Jacobson, I., The Unified Modeling Language User Guide, 1999, Addison Wesley Longman Inc. [26] C. LeBlanc and E. Stiller, “UML for Undergraduate Software Engineering”, JCSC 15, 5 (May 2000), Consortium for Computing in Small Colleges. [27] K. Thramboulidis, “Unified Modeling Language: The Industry Standard for Object-Oriented Development”, chapter in Industrial Information Technology Handbook, CRC Press, (forthcoming). [28] B. Douglas “Doing Hard Time: Developing Real_time Systems with UML, Objects, Frameworks, and Patterns”, Addison Wesley 1999. [29] H. Gomma, Designing Concurrent, Distribute, and Real-Time Applications with UML, Addison Wesley 2000. [30] K., Young, R. Piggin, P. Rachitrangsan, “An Object-Oriented Approach to an Agile Manufacturing Control System Design”, Int. Journal of Advanced Manufacturing Technology, Vol. 17, Springerverlag 2001. [31] H. Mosemann, F. Wahl, “Automatic Decomposition of Planned Assembly Sequences Into Skill Primitives”, IEEE transactions on Robotics and Automation, Vol. 17, No. 5, October 2001. [32] K. Thramboulidis, “Model Integrated Mechatronics: An Architecture for the Model Driven Development of Mechatronic Systems”, 2nd IEEE International Conference on Mechatronics, Istanbul, Turkey 2004. [33] J. Rumbaugh, I. Jacobson, G., Booch, The Unified Modeling Language – Reference Manual, 1999, Addison Wesley Longman Inc. [34] IEC Technical Committee No. 65C: Digital Comm., WG 7: Function blocks for Process Control , IEC1804 General Requirements, IEC Draft 1999 [35] V.Vyatkin, H.Hanisch, “Formal-modelling and Verification in the Software Engineering Framework of IEC61499:a way to selfverifying systems”, IEEE Conference on Emerging Technologies in Factory Automation (ETFA'01), Proceedings, Nice, pp 113-118, 1518 October, 2001. [36] X. Brennan, X. Norrie, “Agents, holons and function blocks: distributed intelligent control in manufacturing, Journal of Applied System Studies”, Special Issue on Industrial Applications of Multi-Agent and Holonic Systems 2(1) (2001), 1-19. [37] M. Fletcher, D. Norrie, “Real-time Reconfiguration using an IEC 61499 Operating System”, International Parallel and Distributed Processing Symposium (IPDPS), San Francisco 2001. [38] K. Thramboulidis, C. Tranoris, “An Architecture for the Development of Function Block Oriented Engineering Support Systems”, IEEE International Conference on Computational Intelligence in Robotics and Automation, Canada, August 2001. [39] K. Thramboulidis and C. Tranoris, “Developing a CASE Tool for Distributed Control Applications”, International Journal of Advanced Manufacturing Technology (forthcoming). [40] R. Brennan, S. Olsen, M. Fletcher, D. Norrie, “Comparing two Approaches to Modelling Decentralized Manufacturing Control Systems with UML Capsules”, Proceedings of the 13th IEEE International Workshop on Database and Expert Systems Applications (DEXA’02). [41] B. Selic, Rumbaugh, J. “Using UML for Modeling Complex realTime Systems”, Rational Software, 1998. [42] K. Thramboulidis, “Using UML for the Development of Distributed Industrial Process Measurement and Control Systems”, IEEE Conference on Control Applications (CCA), September 2001, Mexico. [43] C. Tranoris, K. Thramboulidis, “Integrating UML and the Function Block concept for the development of distributed control applications,” 9th IEEE International Conference on Emerging Technologies and Factory Automation, Lisbon, Portugal, 16-19 September 2003. [44] J. Sztipanovits, G. Karsai, “Model Integrated Computing”, IEEE Computer, April 1997. [45] K. Thramboulidis, G. Doukas, A. Frantzis, “Towards an Implementation Model for FB-based Reconfigurable Distributed Control Applications”, 7th International Symposium on Object-oriented Real-time Distributed Computing (ISORC’04), Viena, Austria 2004. [46] Peter S. Manesis, “Function Block to C++ Model Transformer”, thesis no 667/2003, Electrical & Computer Engineering, October 2003 [in Greek]
ess and allow the schedulability analysis of the control application as well as its deployment to the execution environment. However, a UML profile for control and automation should provide the best alternative for the development of control applications. Such a profile should primarily intend to tailor UML towards the control and automation domain. It should provide to modelers: a) access to common model elements, and b) terminology from the control and automation domain. VII. ACKNOWLEDGMENTS I gratefully thank the CORFU development group and especially Peter Manesis for the prototype implementation of the FB-to-C++ model transformer, and Alexandros Fantzis for the prototype implementation of the TBCS using IBM’s RT Rose. VIII. REFERENCES [1] [2]
[3] [4]
[5] [6] [7]
[8]
[9]
[10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[21] [22]
R. Lewis, Modeling control systems using IEC 61499, The Institution of Electrical Engineers, 2001. B. Heck, Wills, L. and Vachtevanos G. “Software Technology for Implementing Reusable, Distributed Control Systems”, IEEE Control Systems Magazine, February 2003. IEC Technical Committee TC65/WG6, IEC61499 Industrial-Process Measurement and Control – Specification, IEC Draft 2000. OMG, “OMG Unified Modeling Language Specification”, Version 1.5, Object Management Group Inc., http://www.omg.org/technology/documents/formal/uml.htm OMG, “UML Profile for Schedulability, Performance, and Time Specification, Ver. 1.0, September 2003. OMG, “Introduction to OMG’s Unified Modeling Language”, available on line, http://www.omg.org/gettingstarted/ what_is_uml.htm. L. Capretz, “A Brief History of the Object-Oriented Approach”, Software Engineering notes vol. 28, no. 2, ACM SIGSOFT, March 2003. R. Wieringa, “A Survey of Structured and Object-Oriented Software Specification Methods and Techniques”, ACM Computing Surveys, Vol. 30, No. 4, December 1998. T. Quatrani, “Introduction to the Unified Modeling Language”, Rational Rose 2001, White paper, Available Online: http://www.rational.com/media/uml/intro_rdn.pdf?SMSESSION=NO G. Booch, Object-Oriented Analysis and Design with Applications, second edition, Benjamin/Cummings Pub. Company, Inc.1994. J. Rumbaugh, et al., Object-Oriented Modeling and Design, Prentice Hall International 1991. I. Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, ACM Press, Addison Wesley 1992. I. Jacobson, G, Booch, J. Rumbaugh, The Unified Software Development Process, Addison Wesley 1999. C. Kobryn, “UML 2001: A Standardization Odyssey”, Communications of the ACM, October 1999, Vol. 42, No.10. D. Crawford, “Editorial Pointers”, Communications of the ACM, November 2002, Vol. 45, No.11. J. Miller, “What UML Should Be”, Communications of the ACM, November 2002, Vol. 45, No.11. C. Kobryn, “Will UML 2.0 Be Agile or Awkward?”, Communications of the ACM, January 2002, Vol. 45, No.1. D. Dori, “Why Significant UML Change is Unlikely”, Communications of the ACM, November 2002, Vol. 45, No.11. J. Miller, “What UML Should Be”, Communications of the ACM, November 2002, Vol. 45, No.11. J. Miller, and J. Mukerji, “Model Driven Architecture (MDA)”, Document number ormsc/2001-07-01, Architecture Board ORMSC, July 9, 2001. Available online: http://www.omg.org/docs/ormsc/0107-01.pdf S. Mellor, “Make Models Be Assets”, Communications of the ACM, November 2002, Vol. 45, No.11. B. Selic, Ramackers, G., Kobryn, C., Evolution Not Revolution”, Communications of the ACM, November 2002, Vol. 45, No.11.
7
2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany [47] OMG, “Model Driven http://www.omg.org.
Architecture”,
available
online,
8
