[ieee 2006 ieee conference on emerging technologies and factory automation - prague, czech republic...

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 other elements necessary to pro-duce the desirable results. The SysML modeling languageis being proposed, by OMG and INCOSE, as a languagethat allows the system description correctly and consis-tently among various participants of the same project(software, mechanical, electrical and others engineers).The objective of this work is to evaluate the SysML pro-posal as a description language for industrial systemsthrough the modeling of an industrial automation unit. Abrief system description of the case study is included, theSysML diagrams will be presented during the system mod-eling and finally comments and considerations about themodels and the modeling task are presented.

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 [1].

There are several proposals that address the use ofUML (Unified Modeling Language) for systems engineer-ing [2] [3]. 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 [4].” However, many system en-gineers believe that UML is sufficiently flexible and ro-bust to support extensions and to address their specificdomains. One of its strong points is the UML special-ization mechanism (that allows several applications, with

their own domain characteristics) to be used together withUML profiles (encapsulating terminologies and specificsubstructures of a specific domain).

It is believed that UML could potentially be a model-ing language for system engineers, considering analysis,design and verification of complex systems, intending toenhance 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 [5].

In 2003, at the same time that UML 2.0 [6] was be-ing defined, OMG launched a RFP (Request For Propos-als) for a definition of a language derived from UML 2.0for systems engineering [7]. This RFP was developed to-gether by OMG and the International Council on SystemsEngineering (INCOSE).

In agreement with the RFP, this new language shouldsupport the specification, analysis, design and verificationof complex systems [8]. 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) [9]. 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 [10].

The objective of this paper is to do a practical evalu-ation of the modeling language SysML, in the sense ofidentifying its capacities and its limitations for the mod-eling of industrial automation systems. It will be used ascase study an experimental automation unit system. In

1451-4244-0681-1/06/$20.00 '2006 IEEE

section 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 [11]

The structural constructions, as well as the structuraldiagrams in UML, define the static and structural elementsused 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 ele-ments (rebuild the core of UML 2.0 packages and includeextensions to provide some basic capabilities and mod-els management); the blocks (reuses and improves 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 (contains the semantics to definehow blocks are extended to be used together with portsand flows); and the constraint blocks (defines 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 other 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.

AutomationDomain.thePlant:ThePlant

«system»

User

Figure 2. Experimental Unit

2

146

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 distributedenvironment, 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-egy implemented through the data acquisition from thefield devices and the presentation of these to the user in

ThePlant«block»

SupervisorySubSystem«block»

1..*

PhysicalSubSystem«block»

1..*

Device«block»

1..*

ControlSubSystem«block»

1..*

1..*

DFI(Bridge)«block»

1

1

Figure 3. BDD - System Structure

a 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 specification that describes 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 necessaryto have a more detailed view of what is performed by aparametric diagram illustrated in Fig. 10.

3

147

PressureDevice«block»

TemperatureDevice«block»

PositionerDevice«block»

CurrentDevice«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..*

Figure 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


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_FLUID


wp1:WaterPump1..* «block»

start():void

eeIn:EletricPower

fIn:FS_FLUID

fOut:FS_FLUIDrsv:Reservoir

1 «block»

fIn:FS_FLUID fOut:FS_FLUID

fOutWP1:FS_FLUID fOutWP2:FS_FLUID

ret:FS_FLUID

ot1:OutflowDevice1..* «block»

fIn:FS_FLUID

fOut:FS_FLUID

ht:HeaterTank1 «block»

pHigh:Pressure

fIn:FS_FLUID fOut:FS_FLUID

tOut:Temperature

ld:FS_FLUID

pLow:Pressure

etIn:EletricCurrent

mt:MixtureTank1 «block» pHigh:Pressure

fIn:FS_FLUIDfOut:FS_FLUID

tempOut:Temperature

ld:FS_FLUIDpLow:Pressure

v1:Valve1..* «block

fOut:FS_FLUID

fIn:FS_FLUID

wp2:WaterPump1..* «block»

start():void

eeIn:EletricPower

fIn:FS_FLUID

fOut:FS_FLUID

ot2:OutflowDevice1..* «block»

fIn:FS_FLUID

fOut:FS_FLUID

pt2:PositionerDevice1..* «block»fOut:FS_FLUID

fIn:FS_FLUID

tt2:TemperatureDevice1..* «block»

AI1_IN:Temperature

lt2:LevelDevice1..* «block»pHigh:Pressure

pLow:Pressure


fOut:FS_FLUID

fIn:FS_FLUID


fOut:FS_FLUID

fIn:FS_FLUIDv9:Valve

1..* «block

fOut:FS_FLUID

fIn:FS_FLUID

ct1:CurrentDevice1 «block»

AO1_OUT:EletricCurrent

lt1:LevelDevice1..* «block»

pHigh:Pressure

pLow:Pressure

tt1:TemperatureDevice1..* «block»

AI1_IN:Temperature

pt1:PositionerDevice1..* «block» fOut:FS_FLUID

fIn:FS_FLUID

v4:Valve1 «block»

fOut:FS_FLUID

fIn:FS_FLUIDv8:Valve

1..* «block

fOut:FS_FLUID

fIn:FS_FLUID

v3:Valve1 «block»

fOut:FS_FLUID

fIn:FS_FLUIDv2:Valve1 «block»

fOut:FS_FLUID

fIn:FS_FLUID


fOut:FS_FLUID

fIn:FS_FLUID

epInWP2:EletricPowerepInWP1:EletricPower fOut:FS_FLUIDfIn:FS_FLUID

Figure 5. IBD - Physical Subsystem

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 users

and the system or between parts of the system it 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. Figure12 shows the case of plant operation.

The State Machine Diagram (STM) is used to show the

4

148

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


FoundationFieldbus_BUS1

plc:PLC1 «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:LevelDevice1..* «block» fbusfp:FS_TDN

od:OutflowDevice1..* «block» fbusfp:FS_TDV

pd:PositionerDevice1..* «block» fbusfp:FS_TP

td:TemperatureDevice1..* «block»fbusfp:FS_TDT

cd:CurrentDevice1 «block»fbusfp:FS_TDC

ethfp:FS_ETH

Figure 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:OPCServer1 «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:Supervisory1 «block»

SV_Cmd

spOPC

SV_Data

td:TemperatureDevice1..* «block»

spOPCTD_Cmd

TD_Data

od:OutflowDevice1..* «block»

PD_Cmd spOPC

PD_Data

ld:LevelDevice1 «block»

PD_Cmd

spOPC PD_Data

cd:CurrentDevice1 «block»

CD_Cmd

spOPC

CD_Data

pd:PositionerDevice1..* «block»

PVD_CmdspOPC

PVD_Data

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:ARTH1 «block»

OUT:

IN_3:

IN_2:

IN_1:

IN_LO:

IN:

ai:AI1 «block»

IN:

OUT: dsp:DSP1 «block»

rs:RS1 «block»

diag:DIAG1 «block»

pid:PID1 «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

Figure 8. IBD - Pressure Device

discrete behavior of the experimental unit through finitestate transitions (Fig. 13). This diagram represents theoperation of the plant in terms of its transitions and states.

ArithmeticEquations«paramConstraint»

OUT:DS-65PV:DS-65GAIN:doubleBIAS:doubleT1:DS-65T2:DS-65T3:DS-65N:int

FlowCompensationLinear«paramConstraint»

OUT = PV * [ T1 / T2 ] * GAIN + BIAS

1..* FlowCompensationSquareRoot«paramConstraint»

OUT = PV * SQR(T1 / (T2 * T3)) * GAIN + BIAS1..*

BTUFlow«paramConstraint»

OUT = PV * (T1 - T2) * GAIN + BIAS1..*

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..*

Figure 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:ArithmeticEquations1 «paramConstraint»

OUT:DS-65PV:DS-65GAIN:doubleBIAS:doubleT1:DS-65T2:DS-65T3:DS-65N:int

T3

T2

T1

ree:RangeExtensionEquation1 «paramConstraint»

PV:DS-65IN:DS-65IN_LO:DS-65RANGE_LO:doubleRANGE_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

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»

Figure 11. UC - Operation Use Cases

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.

The Activity Diagram (ACT) emphasizes the inputsand outputs, sequences and conditions. It provides a flex-

5

149

SuperviseThePlantRef

AdjustingControlParametersRef

opt

SensorInputsRef

ActuatorOutputsRef

ControlStrategyActionRef

parallel

parallel

loop

user:User thePlant:ThePlant

sd StartThePlantRef

StopThePlantRef

Figure 12. SD - Operation Sequence

Off

OperateThePlant

Controling

Actuating

Controlling

Acquiring

Supervising

start stop

turn_off

Figure 13. STM - Operation State Machine

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-tions about the systems behavior may be traced by thisdiagram.

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

Figure 14. ACT - Control Strategy

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»


«allocation»

«allocation»


«allocation»

ControlStrategy

«refine»

SatisfiedBy:Control Level Activity Diagram

gy

Figure 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(such as the block definition diagram or the internal blockdiagram) 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 allocated on each specific devicein a control strategy level.

Source Target (Device)Level Outflow Positioner

Read Level XRead Reference XControl Level XControl Outflow XPosition Valve X

Table 1. Allocation Matrix.

6

150

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-ent form an object-oriented software modeling, and forthis purpose some diagrams were modified to show sys-tem characteristics.

In UML it is common to listen that “20% UML dia-grams made 80% UML modelling work”. In SysML dia-grams it is not the same. Each diagram is interrelated withanother performing an hierarchical structure that showswhat the system does and how the system work.

The most useful diagram depends on what the systemengineer wants to show. But, the new and modified dia-grams have some strengths and weaknesses that must beanalyzed.

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 onewants 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 system modeling. Initially, therequirement diagram was perceived as a great improve-ment over UML models, because it shows how the re-quirements are satisfied by the system elements. Those re-quirements may be provided by the user, the environment,or by the system itself. Even so, it presents a high de-gree of informality. Requirements are described throughtext based on natural language. It may insert inconsis-tencies during the extraction of information from the di-agram. However, requirements can be grouped in a clearway, also documenting their origin (standards or more de-tailed specifications) or tracing their destination. The re-quirements also can be used to provide useful acceptancetests 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 signal processing that, once modeled, they aid in thedefinition 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 to

verify discrete and continuous behavior together.The state machine diagram and also the sequence dia-

gram provide the same structure 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 way similar 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 itmay be required a more abstract level to represent the sys-tem elements and other domain models (software, elec-trical, mechanical models) can be used to represent thedetailed elements. In this viewpoint, SysML is a powerfullanguage to integrate a great variety of domains in a firstmodeling stage that can be used for 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 a view 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.

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 forthose 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 has

7

151

supported 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 by 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] E. Rechtin and M. Maier, Art of Systems Architecting,CRC Press, Boca Raton, 2 edition, June 2000.

[2] M. Hause, “Rebuilding the Tower of Babel – The Case forUML Extension”, in INCOSE UK Spring Symposium 2001Proccedings, 2001. INCOSE UK Chapter – InternationalCouncil on Systems Engineering.

[3] M. Hause, “Building a Systems Engineering OntologyUnsing UML”, in INCOSE International Symposium 2003Proccedings, 2003. INCOSE – International Council onSystems Engineering.

[4] UML, “Unified Modeling Language”,http://www.uml.org/, March 2006.

[5] M. Hause, F. Thom, and A. Moore, The Systems ModellingLanguage (SysML), White Paper. Artisan Software, 2004.

[6] OMG, Unified Modeling Language: Superstructure, ver-sion 2.0. Object Manegement Group, August 2005.

[7] OMG, “UML for Systems Engineering”, Request For Pro-posals - RFP ad/2003-3-41, Object Management Group,Needham, September 2003.

[8] OMG, “Object Manegement Group”,http://www.omg.org/, March 2006.

[9] SEDSIG, “Systems Engineering Domain Special InterestGroup”, http://syseng.omg.org/, March 2006.

[10] OMG SysML, “The OMG Systems Modeling Language”,http://omgsysml.org/index.htm, May 2006.

[11] SysML Merge Team, Systems Modeling Language(SysML) Specification, version 1.0 (DRAFT). Object Ma-negement Group (OMG), April 2006.

8

152

[ieee 2006 ieee conference on emerging technologies and factory automation - prague, czech republic...

Documents