Empirical Evaluation of SysML through the Modeling of an IndustrialAutomation Unit
Marcos Vinicius Linhares, Alexandre Jose da Silva, Romulo Silva de OliveiraFederal University of Santa Catarina
Campus Universitario – TrindadeCEP:88040-900, Florianopolis, Brazil
marcos, ajs, [email protected]
Abstract
Industrial automation systems may include people,hardware, software and others necessaries to produce thedesirable results. The SysML modeling language is be-ing proposed, by OMG and INCOSE, as a language thatallows the system description correctly and consistentlyamong various participants of the same project (software,mechanical, electrical and others engineers). The objec-tive of this work is to evaluate the SysML proposal as adescription language for industrial systems through themodeling of an industrial automation experimental unit. Abrief system description of the case study will be made, theSysML diagrams will be presented during the system mod-eling and finally the comments and considerations aboutthe models and the modeling task.
1 Introduction
A system is a construction or collection of different el-ements that together they produce results that cannot beobtained by each one of its elements in separate. The el-ements, or their subparts, can include people, hardware,software and other necessary ways to produce the desiredresults [6].
There are several proposals that address the use ofUML (Unified Modeling Language) for systems engineer-ing [1] [2]. Each approach has its own deficiencies. Some-times they create separate models that are difficult to inte-grate. Some of them break up with the standardized char-acteristics of UML.
Those that know UML find it to be an efficient model-ing language, but its roots are firmly fixed in the softwaremodeling area. The Object Management Group (OMG),responsible for maintaining the UML language, estab-lishes that the “UML is a visual and general purpose lan-guage used to specify, to visualize and to document mod-els of software systems [9].” However, many system en-gineers believe that UML is sufficiently flexible and ro-bust to support extensions and to address its use for the
needs of their specific domains. One of its strong pointsis the UML specialization mechanism that allows severalapplications, with their own domain characteristics, canbe used together with UML profiles (encapsulating termi-nologies and specific substructures of a specific domain).
It is believed that UML could potentially be a model-ing language for system engineers, contemplating analy-sis, design and verification of complex systems, intendingto enhance system qualities, increasing the capacity to ex-change information among many engineering tools and tohelp to fill the gap between systems and software engi-neers [3].
In 2003, at the same time that UML 2.0 was beingdefined, OMG launched a RFP (Request For Proposals)for a definition of a language similar to UML for sys-tems engineering. This RFP was developed together byOMG and the International Council on Systems Engineer-ing (INCOSE).
In agreement with the RFP, this new language shouldsupport the specification, analysis, design and verificationof complex systems [4]. It should be done by captur-ing information of the system in a precise and efficientway, facilitating integration and reused in a larger context;analyzing and evaluating the specified systems, to iden-tify and to solve requirements of the system, to distributeprojects and to support exchange among them; communi-cating the information of the systems, correctly and con-sistently among several participants of the same project(software, mechanical, electrical and other engineers).
In response to this RFP, it was created the SystemsModeling Language (SysML) [7]. The objective of thiswork is to empirically evaluate the proposal of SysML as alanguage for description of industrial systems through themodeling of an experimental industrial automation unit.There are some SysML draft documents, but in this paperwe use, at this moment, the latest version (1.0) which isbeing evaluated by the Analysis and Design Task Force(ADTF) group to become the adoption process by theOMG. It was renamed as OMG SysML [5].
The objective of this paper is to do a practical evalu-ation of the modeling language SysML, in the sense of
ETFA'2006 - 11th IEEE International Conference on Emerging Technologies and Factory AutomationPrague, Czech Republic, 20-22 September 2006
identifying its capacities and its limitations for the mod-eling of industrial automation systems. It will be used ascase study an experimental automation unit system. Insection 2, the SysML language is presented. In section3, the experimental automation unit system case studyis described. In section 4 the system is modeled usingthe SysML diagrams. The section 5, contains commentsabout the experience with SysML in the modeling of anindustrial automation system. Section 6, has the final con-siderations.
2 The Systems Modeling Language(SysML)
SysML is designed to provide simple but powerful con-structions for the modeling of a great variety of systemengineering problems. It reuses a subset of the UML2.0 models. This subset is called UML4SysML. Sincethat some models were modified, it is actually a profileof UML for SysML. It also provides additional construc-tions, with the objective of satisfying the needs of systemengineering and the requirements of OMG.
It is particularly effective for specifying structure, be-havior, requirements and constraints on properties of thesystem to support analysis. SysML should be supportedby two evolving interoperability standards, OMG XMI 2.1(standard for the exchange of information among model-ing tools using UML 2.0) and ISO AP233 (standard forthe exchange of information among engineering tools).
Figure 1 shows the modifications in the diagramsreused from UML 2.0 as well as the new diagrams ofSysML. The specification of SysML is classified in threebasic types of models: the structure models, the behav-ior models and the requirement models. For each onethere are defined constructions that are used in a specificmodel. Some constructions can be used together with sev-eral model types. The constructions, as well as the mod-els, are also classified in three types: the structural, thebehavioral and the cross-cutting constructions.
SysMLDiagrams
BehaviorDiagrams Diagram
Structure
ActivityDiagram Diagram
Sequence
State MachineDiagramDiagram
Use Case
RequirementDiagram
PackageDiagram
Block DefinitionDiagram
DiagramParametric
Internal BlockDiagram
Modified from UML2.0
New diagram
Same as UML2.0
Figure 1. SysML Diagrams [8]
The structural constructions, as well as the structuraldiagrams in UML, define the static and structural elements
used in SysML. The diagrams that include the structuralconstructions are: Package Diagram, Block Definition Di-agram, Internal Block Diagram and the Parametric Dia-gram.
Some structural generic elements are: the model el-ements (rebuild the core of UML 2.0 packages and in-clude extensions to provide some basic capabilities andmodels management); the blocks (reuse and improve theclass structure of UML 2.0 to provide the basic capabil-ity of describing the decomposition and interconnectionof the system, and also different types of system proper-ties); the ports and flows (contain the semantics to definehow blocks are extended to be used together with portsand flows); and the constraint blocks (define how blocksare extended to be used with the Parametric Diagram thatmodels the constraint network on system properties, thatis to give support to the reliability analysis and others anal-ysis).
The behavioral constructions specify the dynamic partsused in the behavior diagrams of SysML, including amongthem: the Activity Diagram (used to describe the controlflow and the input and output flow among the actions), theSequence Diagram, the State Machine Diagram and theUse Case Diagram, the same ones used in UML with littleor any modification. The behavior constructions used inthe diagrams are divided in: activities (basically, the sameones defined in UML 2.0 with some extensions to allowcontinuous elements as activity parts); interactions (whereit is defined the constructions for the behavior based onmessages used in the Sequence Diagram); State Machines(used to describe the behavior of a system based on itsstates and its transitions); and Use Cases (they describethe behavior and the use of a system in terms of its highlevel functionality, like in UML).
3 The Case Study
In the Systems and Automation Department at FederalUniversity of Santa Catarina (UFSC) there is an experi-mental unit of industrial automation that is used to demon-strate the operation of several control strategies using thesame equipments and supervision tools. Figure 2 illus-trates the experimental unit.
The experimental unit uses Foundation Fieldbus as thecommunication network and it allows the implementationof applications controlling the flow, level and temperatureof a fluid. The unit is composed by several intelligent de-vices, and a PLC (Programmable Logical Controller), in-tegrated in the network by an universal bridge that allowsthe connection of an Ethernet network to a FoundationFieldbus. It also has a station for operation and supervi-sion of the unit, constituted of a computer and supervisionsoftware. This software receives data acquired in the plantand presents it on the computer screen. That integrates thesupervision and the control levels of the unit.
The intelligent devices based on the Foundation Field-bus technology are capable of executing, in a distributed
2
ETFA'2006 - 11th IEEE International Conference on Emerging Technologies and Factory AutomationPrague, Czech Republic, 20-22 September 2006
AutomationDomain.thePlant:ThePlant
«system»
User
ibdContextDiagram.pdf 1ibdContextDiagram.pdf 1 20/4/2005 18:56:0020/4/2005 18:56:00Figure 2. Experimental Unit
environment, all the necessary control strategies for an in-dustrial application. As a whole, the experimental unithas 9 intelligent devices: 2 valves, 4 pressure devices(2 to measure level and 2 to measure flow), 2 temper-ature sensors devices and 1 current device. The experi-mental unit is complemented by other equipments such asfrequency inverters, resistances, temperature transmitters,valves solenoids, optical level sensor, pumps and others.
4 The SysML Modeling
The experimental unit was used to evaluate SysMLmodeling. SysML models describe its structure, behav-ior and requirements from the point of view of the systemengineer.
The Block Definition Diagram (BDD) describes thestructure of the system or of a subsystem by using theblock as its basic unit. The relationships among them(composition, inheritance, aggregation and others) and thediagram format are the same ones used in the Class Dia-gram of UML 2.0. Figure 3 illustrates the Block Defini-tion Diagram for the experimental unit system. It is com-posed by three subsystems. The experimental unit wasdivided in: physical subsystem, control subsystem andsupervision subsystem. This BDD also shows how eachsubsystem is connected with each other. For example, thecontrol subsystem uses the smart devices to control thephysical subsystem.
The physical subsystem is the part of the system whichshows the physical structure in terms of installed equip-ment. The block definition diagram shown by Figure 4 il-lustrates this subsystem. It is composed by different typesof equipments such as valves, transducers, tanks and thedevices that connect the physical subsystem to the controlsubsystem.
The control subsystem contains the parts of the systemresponsible for the execution of the control strategies. Itincludes the Foundation Fieldbus network, the PLC andthe universal bridge that connects the controlled plant tothe supervision system. The supervision subsystem is re-sponsible for verifying the operation of the control strat-
ThePlant
«block»
SupervisorySubSystem
«block»
1..*
PhysicalSubSystem
«block»
1..*
Device
«block»
1..*
ControlSubSystem
«block»
1..*
1..*
DFI(Bridge)
«block»
1
1
bddThePlantStructure.pdf 1bddThePlantStructure.pdf 1 20/4/2005 18:52:5120/4/2005 18:52:51Figure 3. BDD - System Structure
egy implemented through the data acquisition from thefield devices and the presentation of these to the user ina graphical form.
The Internal Block Diagram (IBD) describes the in-ternal structure of a block, its parts and the connectionsamong them. The connections are made through the useof flow ports, where matter, energy or data may flow. Ser-vice ports connect the services provided and/or requestedby a certain block. Figure 5 shows how the equipmentsare installed in the experimental unit. The flow of severalelements can be seen in the system, including both the di-rection of the flow and the specification of what flows. Forexample, FS FLUID specifies a fluid (flow specification)that passes for several elements of the system. It can beanything from water to some petroleum by-product.
Figure 6 shows the IBD of the control subsystem. It de-scribes the interconnection of several devices of the plantin a Foundation Fieldbus. It can be noticed the existenceof the flow specifications that describe what is flowingamong the equipments installed in the network. Figure 7shows how the devices are connected with the supervisionstation. It presents a service view, that is, a logical viewof the system. In this case the used ports are service portsand not flow ports. Since they are reused from UML, theyinclude all the associated elements, such as the requestedinterfaces and the provided interfaces by the specified ser-vices.
In order to support analysis tasks, the Parametric Dia-gram models a network of constraints on the properties ofthe system. It can be used to identify performance param-eters, relationships among parameters and mathematicalformulas, static values or other parameters that integratethe network of constraints. The pressure device, showedin the Fig. 8 has some function blocks like AI (analoginput functions), DSP (display functions), ARTH (arith-metic functions) and others. The relationship between theparametric constraints of the ARTH block can be seen inFig. 9. It illustrates the various types of arithmetic equa-tions used in this function block. In order to know how thearithmetic function performs its operations it is necessary
3
ETFA'2006 - 11th IEEE International Conference on Emerging Technologies and Factory AutomationPrague, Czech Republic, 20-22 September 2006
PressureDevice
«block»
TemperatureDevice
«block»
PositionerDevice
«block»
CurrentDevice
«block»
PhysicalSubSystem
«block»
1..*
1..*
1
Device
«block»
Tank
«block»
WaterPump
«block»
1..*
MixtureTank
«block»
1
HeaterTank
«block»
1Reservoir
«block»
1
Valve
«block»
1..*
OutflowDevice
«block»
1..*
LevelDevice
«block»
1..*
bddPhysicalSubsystem.pdf 1bddPhysicalSubsystem.pdf 1 20/4/2005 18:47:0820/4/2005 18:47:08Figure 4. BDD - Physical Subsystem
fOut:FS_FLUID
fIn:FS_FLUID
eeIn:EletricPower
ret:FS_FLUID
fOutWP2:FS_FLUIDfOutWP1:FS_FLUID
fOut:FS_FLUIDfIn:FS_FLUID
fOut:FS_FLUID
fIn:FS_FLUID
fIn:FS_FLUID
fOut:FS_FLUID
etIn:EletricCurrent
pLow:Pressure
ld:FS_FLUID
tOut:Temperature
fOut:FS_FLUIDfIn:FS_FLUID
pHigh:PressurepLow:Pressure
ld:FS_FLUID
tempOut:Temperature
fOut:FS_FLUID fIn:FS_FLUID
pHigh:Pressure
AO1_OUT:EletricCurrent
AI1_IN:Temperature
fIn:FS_FLUID
fOut:FS_FLUID
pLow:Pressure
pHigh:Pressure
fOut:FS_FLUID
fIn:FS_FLUID
eeIn:EletricPower
fOut:FS_FLUID
fIn:FS_FLUID
fIn:FS_FLUID
fOut:FS_FLUID
AI1_IN:Temperature
pLow:Pressure
pHigh:Pressure
fIn:FS_FLUID fOut:FS_FLUIDepInWP1:EletricPower epInWP2:EletricPower
fIn:FS_FLUID
fOut:FS_FLUID
fIn:FS_FLUID
fOut:FS_FLUID
fIn:FS_FLUID
fOut:FS_FLUID
fIn:FS_FLUID
fOut:FS_FLUID
fIn:FS_FLUID
fOut:FS_FLUID
fIn:FS_FLUID
fOut:FS_FLUIDfIn:FS_FLUID
fOut:FS_FLUID
fIn:FS_FLUID
fOut:FS_FLUID
PhysicalSubSystem
«block»
wp1:WaterPump
1..* «block»
start():void
eeIn:EletricPower
fIn:FS_FLUID
fOut:FS_FLUID
rsv:Reservoir
1 «block»
fIn:FS_FLUID fOut:FS_FLUID
fOutWP1:FS_FLUIDfOutWP2:FS_FLUID
ret:FS_FLUID
ot1:OutflowDevice
1..* «block»
fIn:FS_FLUID
fOut:FS_FLUID
ht:HeaterTank
1 «block»
pHigh:Pressure
fIn:FS_FLUID fOut:FS_FLUID
tOut:Temperature
ld:FS_FLUID
pLow:Pressure
etIn:EletricCurrent
mt:MixtureTank
1 «block» pHigh:Pressure
fIn:FS_FLUIDfOut:FS_FLUID
tempOut:Temperature
ld:FS_FLUIDpLow:Pressure
v1:Valve
1..* «block
fOut:FS_FLUID
fIn:FS_FLUID
wp2:WaterPump
1..* «block»
start():void
eeIn:EletricPower
fIn:FS_FLUID
fOut:FS_FLUID
ot2:OutflowDevice
1..* «block»
fIn:FS_FLUID
fOut:FS_FLUID
pt2:PositionerDevice
1..* «block»fOut:FS_FLUID
fIn:FS_FLUID
tt2:TemperatureDevice
1..* «block»
AI1_IN:Temperature
lt2:LevelDevice
1..* «block»pHigh:Pressure
pLow:Pressure
v6:Valve
1..* «block
fOut:FS_FLUID
fIn:FS_FLUID
v7:Valve
1..* «block
fOut:FS_FLUID
fIn:FS_FLUIDv9:Valve
1..* «block
fOut:FS_FLUID
fIn:FS_FLUID
ct1:CurrentDevice
1 «block»AO1_OUT:EletricCurrent
lt1:LevelDevice
1..* «block»
pHigh:Pressure
pLow:Pressure
tt1:TemperatureDevice
1..* «block»
AI1_IN:Temperature
pt1:PositionerDevice
1..* «block» fOut:FS_FLUID
fIn:FS_FLUID
v4:Valve
1 «block»
fOut:FS_FLUID
fIn:FS_FLUIDv8:Valve
1..* «block
fOut:FS_FLUID
fIn:FS_FLUID
v3:Valve
1 «block»
fOut:FS_FLUID
fIn:FS_FLUIDv2:Valve
1 «block»
fOut:FS_FLUID
fIn:FS_FLUID
v5:Valve
1..* «block
fOut:FS_FLUID
fIn:FS_FLUID
epInWP2:EletricPowerepInWP1:EletricPower fOut:FS_FLUIDfIn:FS_FLUID
ibdPhysicalSubsystem.pdf 1ibdPhysicalSubsystem.pdf 1 24/4/2005 16:53:5324/4/2005 16:53:53Figure 5. IBD - Physical Subsystem
to have a more detailed view of what is performed by aparametric diagram illustrated in Fig. 10.
The objective of the Use Case Diagram (UC) is toshow, in a simplified way, the behavior of a system to anagent that is external to the system. It presents the systemfrom the user’s perspective, including functions, servicesand identifying which user is related to them. This dia-gram is used to describe how the system is used. Figure11 shows the unit from the point of view of its operation.Of all the diagrams, the Use Case is the most abstract, flex-ible and informal. It serves as the base for other diagrams,
specially the sequence diagram.
In order to describe the control flow between the usersand the system or between parts of the system is usedthe Sequence Diagram (SD). It identifies the sequence inwhich the events happen in a certain process or case. Itshows the elements involved in the dispatch of the eventsand the order in which they are dispatched. This diagramis based on the use case diagram, usually a sequence dia-gram for each use case. Obviously the sequence diagramis also related with the block definition diagram sincethese are the interaction elements of the system. Figure
4
ETFA'2006 - 11th IEEE International Conference on Emerging Technologies and Factory AutomationPrague, Czech Republic, 20-22 September 2006
fbusfp:FS_TP
fbusfp:FS_TDT
fbusfp:FS_TDC
fbusfp:FS_TDN
fbusfp:FS_TDV
rs485fp:FS_CLP
tdt:FS_TDTtdn:FS_TDN tdv:FS_TDVtp:FS_TPtdc:FS_TDC
clp:FS_CLPpc:FS_ETH
ethfp:FS_ETH
ControlSubSystem
«block»
FoundationFieldbus_BUS1
plc:PLC
1 «block»
rs485fp:FS_CLP
dfi:DFI(Bridge)
1 «block»
pc:FS_ETH clp:FS_CLP
tdc:FS_TDC tp:FS_TP tdv:FS_TDVtdn:FS_TDN tdt:FS_TDT
ld:LevelDevice
1..* «block» fbusfp:FS_TDN
od:OutflowDevice
1..* «block» fbusfp:FS_TDV
pd:PositionerDevice
1..* «block» fbusfp:FS_TP
td:TemperatureDevice
1..* «block»fbusfp:FS_TDT
cd:CurrentDevice
1 «block»fbusfp:FS_TDC
ethfp:FS_ETH
ibdControlSubsystem.pdf 1ibdControlSubsystem.pdf 1 24/4/2005 16:32:4124/4/2005 16:32:41Figure 6. IBD - Control Subsystem
SV_Data
spSV
PD_Data PD_Cmd
spLD
PVD_Data
spPVD
TD_Data
spTD
PD_Data
spOD
CD_Data
spCD
SV_Cmd
spOPC
PVD_CmdspOPC
spOPC
PD_Cmd spOPC
CD_Cmd
spOPC
PD_Cmd
spOPC
CD_Data PVD_Data
TD_Cmd
TD_Data
PD_Data
PD_Data
SV_Data
SV_Cmd
CD_Cmd PVD_Cmd
TD_Cmd
PD_Cmd
SupervisorySubSystem
«block»
opc:OPCServer
1 «block»
CD_Data
spCD
CD_Cmd
PD_Data
spOD
PD_Cmd
TD_Data
spTD
TD_Cmd
PVD_Data
spPVD
PVD_Cmd
PD_Data PD_Cmd
spLD
SV_Data
spSV
SV_Cmd
supervisory:Supervisory
1 «block»
SV_Cmd
spOPC
SV_Data
td:TemperatureDevice
1..* «block»
spOPCTD_Cmd
TD_Data
od:OutflowDevice
1..* «block»
PD_Cmd spOPC
PD_Data
ld:LevelDevice
1 «block»
PD_Cmd
spOPCPD_Data
cd:CurrentDevice
1 «block»
CD_Cmd
spOPC
CD_Data
pd:PositionerDevice
1..* «block»
PVD_CmdspOPC
PVD_Data
ibdSupervisorySubsystem.pdf 1ibdSupervisorySubsystem.pdf 1 24/4/2005 16:48:4824/4/2005 16:48:48
Figure 7. IBD - Supervisory Subsystem
IN:
IN_LO:
IN_1:
IN_2:
IN_3:
OUT:
OUT:
IN:
CAS_IN:
IN:
FF_VAL:
TRK_VAL:
TRK_IN:
BKCAL_IN:
OUT:
BKCAL_OUT:
PD_Cmd
PD_Data
spOPC
ARTH_IN:
ARTH_IN_LO:
ARTH_OUT:
ARTH_IN_1:
ARTH_IN_2:
ARTH_IN_3:
AI_IN:
AI_OUT:
PID_BKCAL_IN:
PID_TRK_IN:
PID_FF_VAL:
PID_IN:
PID_CAS_IN:
PID_OUT:
PID_BKCAL_OUT:
PID_TRK_VAL:
Device::PressureDevice
«block»
arth:ARTH
1 «block»
OUT:
IN_3:
IN_2:
IN_1:
IN_LO:
IN:
ai:AI
1 «block»IN:
OUT:dsp:DSP
1 «block»
rs:RS
1 «block»
diag:DIAG
1 «block»
pid:PID
1 «block»
BKCAL_OUT:
OUT:
BKCAL_IN:
TRK_IN:
TRK_VAL:
FF_VAL:
IN:
CAS_IN:
PID_TRK_VAL:
PID_BKCAL_OUT:
PID_OUT:
PID_CAS_IN:
PID_IN:
PID_FF_VAL:
PID_TRK_IN:
PID_BKCAL_IN:
AI_OUT:
AI_IN:
ARTH_IN_3:
ARTH_IN_2:
ARTH_IN_1:
ARTH_OUT:
ARTH_IN_LO:
ARTH_IN:
PD_Cmd
PD_Data
spOPC
ibdPressureBlockStructure.pdf 1ibdPressureBlockStructure.pdf 1 30/4/2005 17:17:0830/4/2005 17:17:08Figure 8. IBD - Pressure Device
12 shows the case of plant operation.The State Machine Diagram (STM) is used to show the
discrete behavior of the experimental unit through finite
ArithmeticEquations
«paramConstraint»
OUT:DS-65
PV:DS-65
GAIN:double
BIAS:double
T1:DS-65
T2:DS-65
T3:DS-65
N:int
FlowCompensationLinear
«paramConstraint»
OUT = PV * [ T1 / T2 ] * GAIN + BIAS
1..* FlowCompensationSquareRoot
«paramConstraint»
OUT = PV * SQR(T1 / (T2 * T3)) * GAIN + BIAS
1..*
BTUFlow
«paramConstraint»
OUT = PV * (T1 - T2) * GAIN + BIAS
1..*
TraditionalMultiplyDivide
«paramConstraint»
OUT = PV * [(T1 / T2) + T3] * GAIN + BIAS
1..*
TraditionalSummer
«paramConstraint»
OUT = (PV + T1 + T2 + T3) * GAIN + BIAS
1..* Average
«paramConstraint»
OUT = [(PV + T1 + T2 + T3) / N] * GAIN + BIAS1..*
FourthOrderPolynomial
«paramConstraint»
OUT = (PV + T1 2 + T2 3 + T3 4) * GAIN +
1..*
HTGCompensationLevel
«paramConstraint»
OUT = [(PV - T1)/(PV - T2)] * GAIN + BIAS
1..*
FlowCompensationApproximate
«paramConstraint»
OUT = PV * SQR(T1 * T2 * T3) * GAIN + BIAS
1..*
bddArithmeticEquations.pdf 1bddArithmeticEquations.pdf 1 30/4/2005 17:25:3630/4/2005 17:25:36Figure 9. BDD - Arithmetic Equations
IN:
IN_LO:
IN_1:
IN_2:
IN_3:OUT:
Device::FunctionBlock::ARTH
«block»
T3=(IN_3 + BIAS_IN_3)*GAIN_IN_3
T2=(IN_2 + BIAS_IN_2)*GAIN_IN_2
T1=(IN_1 + BIAS_IN_1)*GAIN_IN_1 arthEq:ArithmeticEquations
1 «paramConstraint»
OUT:DS-65
PV:DS-65
GAIN:double
BIAS:double
T1:DS-65
T2:DS-65
T3:DS-65
N:int
T3
T2
T1
ree:RangeExtensionEquation
1 «paramConstraint»
PV:DS-65
IN:DS-65
IN_LO:DS-65
RANGE_LO:double
RANGE_HI:double
PV = (g * IN) + (1 - g) * IN_LO, whereg = (IN - RANGE_LO) / (RANGE_HI - RANGE_LO)
PV
RANGE_HI
«Attribute»
RANGE_LO
«Attribute»
GAIN
«Attribute»
BIAS
«Attribute»
ARITH_TYPE
«Attribute»
OUT:IN_3:
IN_2:
IN_1:
IN_LO:
IN:
T3
T2
T1
PV
parArithmeticFunctionBlock.pdf 1parArithmeticFunctionBlock.pdf 1 30/4/2005 18:02:0130/4/2005 18:02:01
Figure 10. PAR - Detailed ARTH Block
User
ThePlant
Operatethe Plant
Stop thePlant
«extend»
Supervisethe Plant
«include»
Control thePlant
«include»
ControlStrategy
«include»
Start thePlant
«extend»
«extend»
«include»
«include»
«include»
«extend»
ucOperationalUseCase.pdf 1ucOperationalUseCase.pdf 1 20/4/2005 19:09:2120/4/2005 19:09:21Figure 11. UC - Operation Use Cases
state transitions (Fig. 13). This diagram represents theoperation of the plant in terms of its transitions and states.The activities of the system can be either continuous ordiscrete and they are represented by their states. When theactivities are continuous it is necessary to use the activitydiagram to represent these in a subsumed state machine.
5
ETFA'2006 - 11th IEEE International Conference on Emerging Technologies and Factory AutomationPrague, Czech Republic, 20-22 September 2006
SuperviseThePlant
Ref
AdjustingControlParameters
Ref
opt
SensorInputs
Ref
ActuatorOutputs
Ref
ControlStrategyAction
Ref
parallel
parallel
loop
user:User thePlant:ThePlant
sd StartThePlant
Ref
StopThePlant
Ref
sdOperateThePlant.pdf 1sdOperateThePlant.pdf 1 24/4/2005 16:59:5524/4/2005 16:59:55Figure 12. SD - Operation Sequence
Off
OperateThePlant
Controling
Actuating
Controlling
Acquiring
Supervising
start stop
turn_off
stmOperateThePlant.pdf 1stmOperateThePlant.pdf 1 29/4/2005 17:25:0229/4/2005 17:25:02Figure 13. STM - Operation State Machine
The Activity Diagram (ACT) emphasizes the inputsand outputs, sequences and conditions. It provides a flex-ible connection between the blocks and their behaviors.This diagram was extended to better support the Func-tional Block Diagrams (EFFBD) and their continuous anddiscrete control flows. Modeling continuous dynamics isimportant in most complex systems where hardware andsoftware integration exist. Figure 14 shows the activitiesfor the level control strategy. This is an example of controlstrategy that can be implemented in the experimental unit.
The Requirement Diagram (REQ) specifies the capa-bility or condition that should be satisfied, traced and/orallocated by the system. The requirements are text basedconstructions related to system model elements. Figure 15shows the requirements for the level control strategy. It ispossible to know which element (block, another diagram,etc.) satisfies the requirement and some others informa-
LevelDevice
«allocate»
Read Level Value
Control theLevel
level
ReadReferenceValue
reflevel
control
level
ref
ref
OutflowDevice
«allocate»
Control theOutflow
Read Outflow Value
flow
control control
flow
flow
PositionerDevice
«allocate»
Position theValve
pos
control
positon_output
«continuous»
outflow_input
«continuous»
level_input
«continuous»
reference_input
«continuous»
level
level
ref
ref
control
flow
flow
pos
control
actLevelControl.pdf 1actLevelControl.pdf 1 30/4/2005 17:15:5430/4/2005 17:15:54Figure 14. ACT - Control Strategy
tions about the systems behavior may be traced by thisdiagram.
ControlLevelStrategy
«Requirement»
Text: "The level must be maintained in 70% of the tank capacity through the level and outflow control of the fluid."
ControlOutflowStrategy
«Requirement»
Text: "The outflow control is maintained by the positioner device that control the flow fluid amount."
«derive»
LevelDevice
«block»
«satisfy»
OutflowDevice
«block»
«satisfy»
TankCapacity
«Requirement»
Text:"The tank capacity is unknowed but the level device sensing the tank filling amount."
«derive»«satisfy»
PositionerDevice
«block»
«satisfy»
ControlSubSystem
«block»
«allocation»
«allocation»
PhysicalSubSystem
«block»
«allocation»
ControlStrategy
«refine»
SatisfiedBy:Control Level Activity Diagram
req ControlStrategy
reqLevelControlStrategy.pdf 1reqLevelControlStrategy.pdf 1 28/6/2005 13:09:1428/6/2005 13:09:14Figure 15. REQ - Control Requirements
The allocation is used by the system engineers to mapelements, activities or other structures of an user modelinto a cross-association that shows where are the relation-ships between each one. The allocation can be representedby a cross-referenced element model into another diagram(like block definition diagram or internal block diagram)or in an allocation sparse matrix.
From the activity diagram, show in Fig. 14, it is pos-sible to generate an allocation matrix (Table 1) for the de-vice elements. This table, in this case, is intended to showwhere the activities are in each specific device in a levelcontrol strategy.
5 Comments on SysML Models
Since SysML is a UML 2.0 subset and some diagramsare imported without modification, it was necessary theuse of support material on UML during the case studymodeling. But, the system modeling task is quite differ-
6
ETFA'2006 - 11th IEEE International Conference on Emerging Technologies and Factory AutomationPrague, Czech Republic, 20-22 September 2006
Source Target (Device)Level Outflow Positioner
Read Level XRead Reference XControl Level XControl Outflow XPosition Valve X
Table 1. Allocation Matrix.
ent form an object-oriented software modeling, and forthis purpose some diagrams were modified to show sys-tem characteristics.
In UML is common to listen that “20% UML dia-grams made 80% UML modelling work”, in SysMLdiagrams it is not be do, each diagram is interre-lated with another performing an hierarchical struc-ture that shows what the systems does and how thesystems work.
The most useful diagram depends on what the systemengineer wants to show and where are seeing the dia-grams. But, the new and modified diagrams have somestrengths and weaknesses that must be analyzed.
The block definition diagram and the internal block di-agram describe the external and internal system structure,respectively. They allow the description of which ele-ments are interconnected and how they are interconnected.They also allow a top-down and/or a bottom-up model-ing giving an abstract/concrete system level to differentsystem elements. Unfortunately, to describe a complexsystem it is important a greater organization because de-pending on the system under modeling, and the view thatwants to show, the number of BDD and IBD diagrams andmodel elements increases very quickly.
The requirement diagram and the parametric diagramare developed for systems engineer needs and they presentan important role during the system modeling. Initially,the requirement diagram was perceived as a great im-provement over UML models, because it shows how therequirements are satisfied by the system elements. Thatrequirements may be provided by the user, the environ-ment, or by the system itself. Even so, it presents ahigh degree of informality. Requirements are describedthrough text based on natural language. It may insert in-consistencies during the extraction of information fromthe diagram. However, requirements can be grouped ina clear way, also documenting their origin (standards ormore detailed specifications) or tracing their destination.The requirements also can be used to provide useful ac-ceptance tests before the system deployment.
The parametric diagram is used to model mathematicaldynamics involved in the system. Since those are specificapplication systems, they present calculations for controland processing of signals that, once modeled, they aid inthe definition of routines with timing constraints.
The activity diagram had little modifications to sup-port continuous elements that are present in many sys-
tems types and it is an important element to the systemengineer. But, the activity diagram are modified fromthe UML 2.0 to support some verification (now it con-tain some elements that looks like a Petri Net) and thisnew model element introduces another challenge, how toverify discrete and continuous behavior together.
The state machine diagram and also the sequence dia-gram provide the same structures models that are used inthe UML models and they are addressed, respectively, todiscrete behavior and message passing behavior.
The use case diagram and the package diagram are thesame as in UML. In a similar way to the design of softwaresystems, these diagrams aid the system modeling duringits initial stage, where the level of abstraction of the sys-tem is high.
The use of some models is not very intuitive. This isjustified by the fact that the same diagram can representdifferent views of the same model, depending on the ele-ments that are used. Depending on the size of the system,the number of diagrams grows very quickly when one in-creases the level of detail. In a very complex system canbe required a more abstract level to represent the systemelements and other domain models (software, electrical,mechanical models) can be used to represent the detailedelements. In this viewpoint the SysML is a powerful lan-guage to integrate a great variety of domains in a firstmodeling stage that can be used to system developmentintegration and control.
6 Final Considerations
In this paper SysML was evaluated as a proposal forthe modeling of industrial automation systems. In spite ofpresenting a steep learning curve, the language allows thebuilding of diagrams that easily represent the structure ofthe system that is being described. Through its diagramsit is possible to have an idea of the final system.
The biggest difficulty faced while using SysML wasnot the fact of it being in a preliminary version. Thebiggest problem is that during a time period of 6 monthsthe specification was changed four times. The last timeit was the beginning of April 2006, when version 1.0 wasintroduced. This last one seems to be stable and the onethat will probably be refined until becoming a standardadopted by OMG.
The use of some diagrams is not very intuitive. Thefact that it is possible, in the same diagram, to rep-resent different views of the same model, dependingon the elements that are used, does not help the sys-tem engineer. Depending on the size of the system, thenumber of diagrams grows very quickly when one in-creases the level of detail. Parece que tem algum coisaparecida logo acima. Qual fica?
Due to the fact that several diagrams were importedfrom UML 2.0, many of the models make reference to theUML specification, including diagrams that were modi-fied. That makes the modeling work more difficult for
7
ETFA'2006 - 11th IEEE International Conference on Emerging Technologies and Factory AutomationPrague, Czech Republic, 20-22 September 2006
those that do not have a previously knowledge of UML.The specification of SysML is a small document whencompared to that of UML. That gives to the system en-gineer the illusion that the work is simple.
For this paper we opted for a more generic view ofthe system and of the physical subsystem, including somenew SysML diagrams in order to evaluate them. Thischoice was motivated by the short available space to ex-pose the plant modeling. The consequence was that sev-eral diagrams that would bring a deeper view of the systemwere left out of the paper. Anyway the included diagramsallow a preliminary evaluation of the potential of SysML.The language is really powerful and to this moment it hassupported the necessities of our modeling. For the systemengineer, it is a language easier to understand when he/shetries to read it than when he/she has to write models withit. In other words, the review of the diagrams for otherengineers won’t demand the same training level that thesystem engineer needs to draw the diagrams.
In spite of the problems, the result is positive. SysMLallows the system engineer to describe the system, includ-ing hardware and software aspects simultaneously withthe other elements of the industrial automation unit. How-ever, SysML modeling requires the project team, gener-ally formed by engineers, to have knowledge of UML.This requirement could be a barrier to its acceptance ina large scale.
For software developers that are used to UML 2.0, theuse of SysML is straightforward. A SysML specificationwould be a much better start for the system developmentthan a specification in natural language or, still worse, sev-eral electrical and mechanical diagrams.
Since the system development team is multidisci-plinary, including professionals from different domains,SysML is a very interesting proposal to improve the com-munication among them. To illustrate such statement weconsider a meeting on certain system elements. An elec-tronic engineer has electronic diagrams, a control engineerhas control diagrams and a software engineer has softwarediagrams. The interaction among the team is minimum,because one does not have knowledge of the modeling lan-guage used by the other. However, if SysML was used, themodeling language would be the same for all the personswith different backgrounds. It would improve the interac-tion among the team and decrease the time to market of asystem.
References
[1] M. Hause. Rebuilding the Tower of Babel – The Case forUML Extension. In INCOSE UK Spring Symposium 2001Proccedings. INCOSE UK Chapter – International Councilon Systems Engineering, 2001.
[2] M. Hause. Building a Systems Engineering Ontology Un-sing UML. In INCOSE International Symposium 2003Proccedings. INCOSE – International Council on SystemsEngineering, 2003.
[3] M. Hause, F. Thom, and A. Moore. The Systems ModellingLanguage (SysML). White Paper. Artisan Software, 2004.
[4] OMG. Object Manegement Group. http://www.omg.org/,March 2006.
[5] OMG. Systems Modeling Language.http://omgsysml.org/index.htm, May 2006.
[6] E. Rechtin and M. Maier. Art of Systems Architecting. CRCPress, Boca Raton, 2 edition, June 2000.
[7] SEDSIG. Systems Engineering Domain Special InterestGroup. http://syseng.omg.org/, March 2006.
[8] S. M. Team. Systems Modeling Language (SysML) Speci-fication. version 0.99. Object Manegement Group (OMG),February 2006.
[9] UML. Unified Modeling Language. http://www.uml.org/,March 2006.
8
ETFA'2006 - 11th IEEE International Conference on Emerging Technologies and Factory AutomationPrague, Czech Republic, 20-22 September 2006