Embed Size (px)
Citation preview
ARTICLE IN PRESS
0967-0661/$ - se
doi:10.1016/j.co
�CorrespondE-mail addr
(D.N. Ramos-H
Control Engineering Practice 15 (2007) 77–94
www.elsevier.com/locate/conengprac
A flexible environment for rapid prototyping and analysis ofdistributed real-time safety-critical systems
H.A. Thompsona, D.N. Ramos-Hernandeza,�, J. Fua, L. Jianga, I. Choia,K. Cartledgeb, J. Fortuneb, A. Brownb
aRolls-Royce University Technology Centre in Control and Systems Engineering, University of Sheffield, UKbRolls-Royce Plc., UK
Received 18 July 2005; accepted 30 April 2006
Available online 3 July 2006
Abstract
Currently, there is a plethora of low-cost commercial off-the-shelf (COTS) hardware available for implementing control systems. These
range from devices with fairly low intelligence, e.g. smart sensors and actuators, to dedicated controllers such as PowerPC,
programmable logic controllers (PLCs) and PC-based boards to dedicated systems-on-a-chip (SoC) ASICS and FPGAs. When
considering the construction of complex distributed systems, e.g. for a ship, aircraft, car, train, process plant, the ability to rapidly
integrate a variety of devices from different manufacturers is essential. A problem, however, is that manufacturers prefer to supply
proprietary tools for programming their products. As a consequence of this lack of ‘openness’, rapid prototyping and development of
distributed systems is extremely difficult and costly for a systems integrator. Great opportunities thus exist to produce high-performance,
dependable distributed systems. However, the key element that is missing is software tool support for systems integration. The objective
of the Flexible Control Systems Development and Integration Environment for Control Systems (FLEXICON) project IST-2001-37269
is to solve these problems for industry and reduce development and implementation costs for distributed control systems by providing an
integrated suite of tools to support all the development life-cycle of the system. Work within the Rolls-Royce supported University
Technology Centre (UTC) is investigating rapid prototyping of controllers for aero-engines, unmanned aerial vehicles and ships. This
paper describes the use of the developed co-simulation environment for a high-speed merchant vessel propulsion system application.
r 2006 Elsevier Ltd. All rights reserved.
Keywords: CORBA; Co-simulation; Distributed systems; Tool support; Systems integration; Obsolescence management
1. Introduction
Industry is extremely wary of adopting distributedsystems due to the step change in complexity that occursleading to increased costs and risks. In order to develop adistributed control system for an entire ship or aircraft, forinstance, it requires tools that can deal with high complex-ity, integrating design information from multiple domainsand allowing analysis of the overall design in terms oftechnical and commercial performance. Currently, nointegrated multi-disciplinary design tools exist which cando this. The ability to simulate and assess system
e front matter r 2006 Elsevier Ltd. All rights reserved.
nengprac.2006.04.005
ing author. Tel.: +44114 221 5400.
ess: [email protected]
ernandez).
performance and rapidly prototype systems is thus critical.In this paper, an integrated suite of tools to support all thedevelopment life-cycle phases: modelling/simulation, codegeneration and implementation, is implemented. The toolsaddress the following features:
�
management of requirements, � management of complexity, � performance assessment during design via multi-disci-plinary co-simulation, and
� management of system component obsolescence.Modelling and co-simulation support is used to assessthe performance of the system from different viewpointsprior to implementation, e.g. control system performance(for hybrid systems with continuous/discrete elements)
ARTICLE IN PRESSH.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–9478
using Simulink and ISaGRAF, fault tolerance for meetingtechnical goals using ARTISAN Unified Modelling Lan-guage (UML) modelling, and availability and through-lifecost modelling in Excel for meeting commercial goals suchas future service contracts.
Many of today’s manufacturers are faced with difficultchallenges including reducing time to market and achievingright first time designs. To do this, they are makingincreasing use of ‘virtual prototyping’ where a computermodel is replacing the physical prototype (in fact, it is tooexpensive to physical prototype an entire ship or aircraftcontrol system). There are many benefits to this approachincluding more rapid development, lower cost, greaternumber of design alternatives evaluated and more optimaldesigns achieved. Although pictures-to-code tools do existfor rapid prototyping of control systems, e.g. MathWorksReal-Time Workshop, the control code only accounts for20% of the problem in a typical practical system. Furthercode is necessary to support databus interfacing, signalconditioning, input/output data checking, and fault detec-tion, isolation and accommodation (FDIA). This function-ality needs to be developed separately and then integratedinto the final system. Thus, in addition to a control systemsengineer’s viewpoint, FDIA and architectural modellingtools are needed to define how the various code modulesshould be allocated to the distributed resources available.
Previously, in the Framework and PiCSI projects(Browne, Bass, & Fleming, 1997; Ramos-Hernandez,Fleming, & Bass, 2005) at the University of Sheffield, theintegration of Simulink, Statemate, UML, ISaGRAF andthe subsequent generation of code for distributed controlsystems was considered. Additionally, work on UnmannedAerial Vehicles has considered the rapid protoyping ofdistributed flight control systems with hardware-in-the-loop (HIL) (Newman, 2005). In the Flexible ControlSystems Development and Integration Environment forControl System (FLEXICON) project, code generationtools have been developed that integrate control law code,signal conditioning, databus interfacing, I/O data checkingand FDIA to allow HIL testing for high-speed ships (gasturbine engine/waterjet propulsion systems). Rapid proto-typing of subsystems allows a powerful means to establishsystem performance and provide confidence in a design.The complexity of the design can be increased andgradually tested in a systems environment using co-simulation. By running the controller code on the targetprocessor, co-simulation helps to determine the controller’smaximum sample rate, memory usage and other require-ments more accurately.
Another aim of the work at Sheffield is to deal withobsolescence management. Obsolescence is a critical issuefor industry due to the increasingly rapid turnover intechnology. It is quite likely that hardware will becomeobsolete within 2–3 years. The lifetime of a system, e.g.ship, aircraft, car, train, process plant, etc., however, can befrom 10 to 30 years. This presents a huge obsolescencemanagement problem. Thus, a flexible approach to code
generation has been developed that allows code to begenerated for a number of targets from a single systemspecification. Target languages that have been consideredare C, IEC 61131-3, Java and VHDL (for FPGAprogramming) with a variety of databus interfaces. Thisallows the support of PowerPC, PC-based boards, pro-grammable logic controllers (PLCs) and embedded intelli-gence interconnected via Ethernet, CAN and Wirelesstechnologies.
2. FLEXICON toolset
There are many commercially available tools specific todifferent application areas. While all have strengths inparticular areas, most do not cover the breadth ofapplications that manufacturers require. Currently, theproblem is that there is no one single tool that coversmultiple disciplines. Also, engineers wish to work withtools that are familiar in their domains. Therefore, it isnecessary to integrate several different tools to modeldifferent aspects of the design. For example, ARTISAN isa UML tool for system modelling familiar to softwareengineers, but it is difficult to simulate the impact of asystem fault using this tool. Simulink/MATLAB is apowerful system simulation tool developed for controlengineers, but it is not good for management systems oranalysis of reliability and cost. Engineers who performreliability and cost modelling are far more familiar withMicrosoft tools such as Excel. Instrumentation engineerswould be unfamiliar with control law design tools such asSimulink/Matlab. They tend to use PLC programmingtools using the IEC 61131-3 standard notation. Thisstandard has existed for several years and has beenadopted by most of the major PLC manufacturers andvendors (Lewis, 1998). A tool that supports IEC 61131-3notation is ISaGRAF Enhanced developed by Altersys(ISaGRAF, 2002). This tool conforms to the languagesdefined in the standard and also generates hardwareindependent TIC (Target Independent Code). The ap-proach adopted in the Framework, PiCSI and FLEXICONprojects therefore has been to integrate several differenttools that allow modelling of different aspects of the designin environments that engineers are most comfortable with.The FLEXICON project overall activities are divided
into three phases: Co-simulation integration, Code Gen-erator Integration and Demonstrator Integration Activities(Thompson & Ramos-Hernandez, 2004). This paperdescribes the first phase that concentrated on gatheringthe requirements for a Marine application and produced anenvironment that allows co-simulation of the differentviews of the system. In the second phase, work addressedthe development and integration of the code generators(Java and VHDL). The final phase, currently underdevelopment, is the construction of a Marine demonstra-tor. FLEXICON is the name of the project and the toolsthat allow Co-simulation with HIL and Code Gene-ration are called the FLEXICON toolset. For Marine,
ARTICLE IN PRESS
Fig. 1. Co-simulation vision.
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–94 79
Automotive and Aerospace applications, this toolset iscalled FLEXICON MAA.
Co-simulation is one of the best ways to developcomplex systems as it allows parts of the system to beintegrated and tested through virtual prototyping (Thomp-son & Ramos-Hernandez, 2004). Fig. 1 shows the ‘vision’for the FLEXICON toolset considering a Marine applica-tion with different commercial off-the-shelf (COTS) toolsfrom the design domains being integrated via an interfaceto Common Object Request Broker Architecture (COR-BA). In the demonstrator where HIL is required, it wasplanned to use Real-Time CORBA instead of CORBA.Although it is feasible to use RT-CORBA, a new middle-ware standard, NDDS, was selected to be used in the finalMarine demonstrator. This is described in Section 3.
The COTS tools that have been integrated within theFLEXICON environment are:
�
1
ISaGRAF for discrete control system modelling,
� Simulink as a continuous system model simulation tool, � ARTISAN as a model building and management tool, � Microsoft Excel for reliability and through-life costcalculation.
3. Co-simulation environment based on CORBA
This paper describes the FLEXICON co-simulationenvironment and how VisiBroker CORBA has been usedto enable co-simulation between the ISaGRAF, Simulink,ARTISAN and Excel tools. The CORBA was selected as itis a standard adopted by the Object Management Group(OMG)1 to enable interoperability between applications in
http://www.omg.org/
heterogeneous distributed environments (Tari andBukhres, 2001). CORBA is the leading middlewarestandard for exchange of information on independenthardware platforms, programming languages and operat-ing systems. Thus, CORBA can be considered as an opensoftware bus, which allows object components created bydifferent operating systems and languages to interoperate.In addition, it can make integration with legacy softwareeasier.CORBA is also conceptualised as a communication bus
for client-server objects (Segue Software, 2003). SinceCORBA is a three-tier distributed object mechanism, theterminology ‘client-server’ applies within the context of aspecific request. That is, if an object A invokes a method onobject B, A is the client and B is the server. If B then callsA, the roles are reversed. Exported server interfaces mustbe specified in the CORBA standard Interface DefinitionLanguage (IDL). An IDL interface description is thenmapped using an IDL compiler to native language bindingssuch as C, C++, Java, COBOL, Smalltalk, Ada, Lisp,Python and IDLscript (OMG-CORBA, 2005). This allowseach programmer to write source code independently in themost appropriate language. For example, a server objectimplemented in C++ can be accessed by a Java applet.The applet programmer invokes methods on the server asthough they are local Java method calls. The ObjectRequest Broker (ORB) is the mediator, responsible forbrokering interactions between objects. Its job is to provideobject location and access transparency by facilitatingclient invocations of methods on server objects. A clientcan connect—or bind—to a server object statically if theserver interface is known at build time. Alternatively, theclient can use dynamic binding to ascertain the serverinterface and construct a call to the server. Servers
ARTICLE IN PRESS
Fig. 2. Request to a remote server.
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–9480
implement services used by clients, and a server may be aclient to another server. Servers are usually multi-threaded,and can also have separate instances running on more thanone node, each of which has its own threads to servicerequest from clients (Cashman, 2001). The followingdiagram (Fig. 2) illustrates a request to a remote server.The ORB delivers the request to the server object andreturns any result to the client object.
CORBA is commonly used on problems that wouldbenefit from the simultaneous application of multipleprocessors over a network. These types of problems usuallyhave one or more of the following requirements:
�
2
3
parallel computations on different processors to im-prove performance,
� scalability which requires the dynamic addition ofcomputational resources,
� fault tolerance in case of processors or network failuresto migrate to others resources.
Thus, CORBA offers many advantages when addressingthe support of distributed systems development. There areseveral tools based on CORBA, such as TAO, VisiBrokerand ORBexpress. In 2002, when the FLEXICON projectstarted, the two most popular tools were VisiBroker andTAO. TAO2 is a C++ ORB that is compliant with mostof the features and services defined in the CORBA 3.0specification, which includes the RT-CORBA specification.TAO (developed at the University of California, Irvine)started to be supported commercially, but it was not widelyused in the industry. This was the concern for potentialusers of the FLEXICON toolset. Thus, VisiBroker3 fromBorland was selected for FLEXICON as it was well knownin the industry. VisiBroker is also a CORBA compliantmiddleware solution and provides seamless developmentacross leading enterprise and embedded/real-time operat-ing systems. In 2004, the new OMG’s middleware standard
http://www.cs.wustl.edu/�schmidt/TAO.html
http://www.highlander.com/index.html
Data Delivery Service (DDS) based on a publisher–sub-scriber design became available and it was a mandatedstandard for use across the Department of Defense (DoD)in USA. The first DDS-compliant product was NDDS byRTI.4 Since then, NDDS has been adopted for marineand aerospace applications in the USA. Thus, NDDS hasbeen recently adopted within the FLEXICON MAAtoolset instead of CORBA. Co-simulation with NDDSand its performance compared with CORBA will bereported in a future paper. The present paper describesthe co-simulation work carried out using the CORBAmiddleware standard.In addition to CORBA and NDDS, there are other
technologies that can be used to integrate heterogeneousdistributed systems, such as Web services, .NET, Message-Oriented Middleware, Transaction Monitors, Grid plat-forms, HLA (previously used in the Virtual Engine andAircraft System Environment at Sheffield, see Stewart andFleming (2001)) and Enterprise Java Beans. However,CORBA and recently NDDS are the de facto standardsused in real-time applications. For instance, in Li andQi (2004), it is highlighted that although CORBA pro-vides high performance, good security and scalability inmanaging components in a distributed computing envi-ronment, the main drawback of this middleware is itslack of true interoperability. The authors then use Webservices (based on SOAP) to augment a previous CORBA-oriented wrapper generator called WSOWG. Thus, non-networked legacy code is leveraged as Web services. Thetesting results for performance evaluation show thatusing SOAP causes considerable performance overheadsbecause its eXtensible Markup Language (XML) parsingand formatting are time consuming. Thus, further workis needed to increase performance if this technologyis going to be used in a real-time, safety-critical appli-cation.
3.1. CORBA approach
Since CORBA allows the exchange of information onindependent hardware platforms, programming languagesand operating systems, the first version of the co-simulation environment is based on this middleware. Toachieve the co-simulation, client-server objects wereimplemented for each COTS tool. An IDL template filewas created and compiled to create the skeleton and stubfor the client and server of the COTS tools described inSection 2 (Thompson et al., 2004).The IDL file created contains the following lines:
//Flexicon.idl
module FlexServer {interface GetServer {
string GetFromServer( in long RW, out long X, out
long Y, out string strGName);
4http
://w ww.rti.com/index.html
ARTICLE IN PRESSH.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–94 81
};
interface SendServer {string SendToServer(in long RW, in long X, in long
Y, in string strSName);
};
interface ControlServer {string ControlInfo(in string strCName);
};
};
The IDL keyword interface is used to tell the IDLcompiler that this is the object interface. Then the functionsthat this interface is going to use are specified. In thisapplication, there are three member functions, GetServer,SendServer and ControlServer. There are three IDL key-words: in, out and inout. If the function takes a parameterthat would only be used by the function and is not usedas a result, the IDL keyword in would be placed in frontof the parameter. If the function takes a parameterthat would only be used as a result and is not used bythe function, the IDL keyword out would be placed infront of the parameter. Furthermore, if the functiontakes a parameter that was going to be both used by thefunction and used to return a value, the keyword inout
would be placed in front of the parameter. The keywordinout was not used in this IDL file. Once the IDL file iswritten, it needs to be compiled into the skeleton and stubusing the VisiBroker tool idl2cpp. Then four files aregenerated (Flexicon_c.cpp, Flexicon_c.hh, Flexicon_s.cpp,
Flexicon_s.hh). These files are used to create the server andclient applications. Thus, the models in each tool can beaccessed using read and write functions. The clientapplication can receive and send data to the server throughthe VisiBroker ORB. The C++ Builder 6 tool was usedto create the CORBA server and client applications(Borland, 2002).
Fig. 3. Integrated Propul
4. Marine application
To provide a challenging and complex application, ahigh-speed ship propulsion system is being considered.Rolls-Royce Marine is developing a new generation of jet-powered high-speed ships through its Scandanavian groupof companies which manufacture gas turbine engines,marine control systems and waterjets. The example shiputilises five gas turbine engines and a sharp long hull thatallows the ship to cut through waves at 50 knots ratherthan ride over them. This allows the ship to maintainhigher speeds than conventional ships even in mid-oceanand bad weather. In such a ship, crossing the Atlanticshould take around 90 h, whereas existing ‘fast’ ships (32knots) take around a week (Thompson, Ramos-Hernan-dez, Cartledge, Fortune, & Brown, 2003). The ships (aboutthe length of three jumbo jets) are predicted to be the mostsignificant development in ocean travel in the past 100years. The first ships will be built to carry cargo but there isalso considerable interest in the market for passenger cruiseships. The propulsion system consists of five MT30 gasturbines, five Kamewa waterjets and gearboxes as shown inFig. 3 controlled by a typical, complex, distributed, real-time, safety-critical Integrated Propulsion Control System(IPCS) for control and monitoring.The IPCS allows the operator to control and monitor all
the propulsion train equipment as an entire system fromthe control consoles. This supervisory control system at thetop level interacts with local equipment controllers thatcontrol the gas turbines, gearboxes and waterjets. TheIPCS can be operated in three control modes: automatic,semi-automatic and manual. In the case of the propulsionequipment, the IPCS interfaces with local control systemscontrolling starting, shutdown and speed of the gasturbines, and speed of the waterjets and their direction.The waterjets (see Fig. 4) provide steering for the ship
and also the ability to rapidly stop through reversal of
sion Control System.
ARTICLE IN PRESS
Fig. 4. Kamewa waterjets.
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–9482
thrust. (Here, there are many analogies with work beingperformed within the Sheffield University TechnologyCentre on rapid prototyping and simulation of thrustvectoring aircraft, see Newman 2005.)
5. Co-simulation for the marine application
The FLEXICON toolset co-simulation environmentbeing developed can be used to rapidly prototype theIPCS by testing discrete and continuous laws developed inISaGRAF and Simulink against a model of the gas turbineengine and waterjet propulsion system with incorporatedship dynamics in Simulink. UML modelling (with theARTISAN Real-time Studio (RtS) tool) is used to definethe hardware architecture redundancy for fault toleranceand the functionality of the control system. Fault injectionscenarios can be injected into Simulink to test out FDIAstrategies. Excel is used to perform reliability and through-life cost modelling of the system. Co-simulation with HILis also possible allowing integration testing of real systemcomponents within the prototyping environment. In thefollowing sections, the various parts of the co-simulationenvironment are described.
5.1. Captains interface
In Fig. 1, the Captain of the Ship interacts with the IPCSvia the Human Machine Interface (HMI), thus he/she cancontrol and monitor the propulsion system. Firstly, theHMI communicates with the ISaGRAF tool that containsthe supervisory mode control (PLC system based). Fourscenarios have been considered: Start-up, Normal Opera-tion, Normal Stop and Emergency Stop. The supervisorymode controller in the ISaGRAF tool then controls theSimulink continuous model of the waterjet propulsionsystem according to the selected mode via CORBA. Thedifferent operating modes (Start-up, Normal Operation,Normal Stop and Emergency Stop) of the gas turbines areperformed using a Sequential Function Chart (SFC) withinISaGRAF. This language was selected as the mostappropriate for this application as it describes thesequential behaviour of a control programme. Note thatit is also possible to implement the modes in the Stateflow
tool within the MathWorks environment (Stateflow, 2002).This tool, however, does not support generation of code forPLCs and is unfamiliar to instrumentation engineers.To initiate each mode, a Graphical User Interface (GUI)
was developed using ISaGRAF’s HMI. Thus, each modecan be activated using an associated pushbutton as shownin Fig. 5. The HMI is not integrated within the co-simulation environment via CORBA, but is implementedwithin the ISaGRAF tool (communication is establishedthrough an OPC Server).The HMI includes a number of pushbuttons to select
different modes. Indicator lamps are also included to showthe various stages of start-up and normal stop as theyprogress. In addition, an overspeed trip alarm is includedfor fault injection experiments. This is described in a latersection on fault injection.
5.2. Co-simulation interface—ISaGRAF and Simulink
The SFC diagram (within ISaGRAF) contains the fourscenarios (start-up, normal operation, normal stop andemergency stop). Each scenario was implemented usingsteps and transitions. The steps are shown as rectangularboxes connected by vertical lines. Each step represents aparticular state of the system being controlled and eachconnecting line has a horizontal bar representing atransition. A transition is associated with a conditionwhich, when true, causes the step before the transition tobe deactivated and the step that follows the transition to beactivated. Transition through the sequence diagram canbe monitored by means of a white token moving aroundthe various steps of the diagram. In a SFC diagram, theflow of control is generally down the page, but branchescan be used to go back to earlier steps (ISaGRAF, 2002).Fig. 6 shows the first two steps and transitions of the ‘start-up’ mode in more detail. The description of the actionsto be performed is defined on the rectangular boxes on theright-hand side of this figure.In order to illustrate the co-simulation between ISa-
GRAF and SIMULINK, the main steps in each mode arelisted in Table 1. For example, to complete the start-upsequence, 12 steps must be completed. If any step fails, thenthe start-up sequence will abort going to the ‘start aborted’step.
5.2.1. Propulsion control in Simulink
To operate the Propulsion System, information isexchanged between the ISaGRAF (SFC model) andSimulink model via a co-simulation interface.The top-level of the Simulink operational mode model is
shown in Fig. 7. The modes have been defined correspond-ing to start-up, normal operation, normal stop andemergency stop. These modes are selected accordingly fromthe HMI via ISaGRAF. The model links these modes to aSimulink simulation of the Waterjet Propulsion Systemand to Fault Injection and Detection subsystem modelsdeveloped in Simulink. Data from ISaGRAF are passed to
ARTICLE IN PRESS
Fig. 5. HMI—mode selection.
Table 1
Summary of the steps used in the supervisory control of the gas turbine
Steps
Start-up Normal stop
Ventilation fan Engine cooling
Purge enclosure Shut off valve
Lubrication oil Metering valve
Fuel forwarding system Ventilation valve
Initiate start Auxil system down
Engine crank Coast down
Purging Engine management system stop
Ignition on Normal operation
Engine management system on System status
Light up Manual stop
Power turbine ramp UP Goto emergency stop
Loading Emergency stop
Start aborted Fuel shut off
Fig. 6. SFC—start-up mode detail.
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–94 83
the Simulink model through the block called FromISa-
GRAF. Outputs from the operation modes are sent backto ISaGRAF via the ToISaGRAF block and to theWaterjet Propulsion System. These two blocks performread and write functions utilising the developed CORBAinterfaces.
Thus, the selected mode is first passed from ISaGRAF toSimulink. Simulink then activates the corresponding modeand the passing of data between both tools duringsimulation is performed. For example, if the start-up modeis selected in ISaGRAF, Simulink will activate this modetoo (case 1), if all the sequence is satisfactory andcommunication between the tools is okay, then normal
operation (case 2) is activated. Case 2 will start the normalrunning of the Waterjet Propulsion System. Case 3corresponds to normal stop and case 4 to emergency stop.After the start-up of the gas turbine engine, the normal
operation mode is activated. This causes the Simulinkmodel to switch to the Waterjet Propulsion Systemoperating in normal simulation mode (case 2).Fig. 8 shows the start-up subsystem and the input and
output ports to ISaGRAF for the start-up sequence of thegas turbine engine. Here, the control systems engineer
ARTICLE IN PRESS
Fig. 7. Simulink model showing operational modes (top-level).
Fig. 8. Simulink start-up mode.
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–9484
needs to identify the parameters that are to be passedbetween ISaGRAF and Simulink. Two scopes were used tomonitor the data transferred between the tools.
5.2.2. Co-simulation results
During co-simulation, the ISaGRAF Server (built inCORBA) updates the ISaGRAF database. Co-simulationresults are shown in Fig. 9. Firstly, it is necessary tostart the gas turbine engine. This is illustrated in the firstplot of this figure. There is no response from the gasturbine engine power turbine (second plot) until thestart sequence is complete and the power turbine is runup (60 s). At this point, the engine transitions into normaloperation.
5.2.3. Fault injection scenario
There are a number of critical failures in the gas turbineengine (mechanical failures or design limit exceedences)that can result in catastrophic failure of the system anddamage. In these cases, an immediate emergency shutdownof the system is performed by activating the fuel shut offvalve. Two types of ‘emergency stop’ scenario can occur.An ‘emergency stop’ can be initiated manually by theCaptain (via HMI, see Fig. 5) or it can be automaticallytriggered (as demonstrated in Fig. 9) when there is criticalfailure (170 s). In the case of a manual ‘emergency stop’,ISaGRAF will communicate this to the Simulink modelwhich will shut off the fuel immediately. For the case of afault which causes an automatic shutdown of the engine(such as the overspeed fault), the fault is injected into the
ARTICLE IN PRESS
Fig. 9. Fault injection GUI.
5http://rational.com/6http://www.artisansw.com
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–94 85
Simulink model. This is detected by appropriate detectionlogic (also incorporated into this model). Simulink alertsISaGRAF which then automatically enters the emergencystop sequence. This shuts off the gas turbine engine. Analarm is also activated on the Captain’s HMI to show thatan emergency shutdown has been performed.
It is also possible to inject failures into sensors andactuators within the system. This is of particular interestfor the development and testing of fault detection andredundancy management schemes.
5.3. Co-simulation with ARTISAN
The next tool in the co-simulation environment is theARTISAN RtS tool. The ARTISAN tool is based on theUML. UML was adopted by the OMG as a standard forsoftware systems engineering. Since its introduction in1997, UML has been widely used by both industry andacademia. However, although it has proven suitable formodelling the qualitative aspects of many softwaresystems, the original definition did not provide a standardmeans for expressing the quantitative aspects of thosesystems. For example, in the real-time domain, it is oftennecessary to specify temporal constraints associated withspecific elements of a model, such as the maximumacceptable duration of certain actions, necessary andavailable communication throughput rates, and time-outvalues. To remedy this, the OMG has supplemented theoriginal UML specification by developing a ‘Real-TimeProfile’ (RT-Profile) (OMG-RT Profile, 2003) that woulddefine standardised ways for specifying temporal propertiesin a UML model. (A profile is the UML extension
mechanism for a tightened semantic interpretation of therelatively general concepts in the standard, intended tomeet the requirements of a particular domain.) The RT-Profile focuses on the modelling of time and time-relatedaspects such as the key characteristics of timeliness,performance and schedulability. The ability to predictthese characteristics based on analysing models of softwareis a fundamental objective of this special profile. Formalquantitative analyses based on the ability to model qualityof service aspects, such as deadlines and priorities, willprovide far better results than relying exclusively onintuition and ‘feel’.There are several tools based on UML for real-time and
among the most popular are Rational Rose RT5 andARTISAN RtS.6 ARTISAN RtS is of particular interestfor this project as powerful real-time extensions areincluded for development of a real-time system andspecially its System Architecture Diagram. The ARTISANVersion used in the project is 4.2 and this is based on UMLVersion 1.4. Currently, the OMG is upgrading all of UMLto Version 2.0 (OMG-UML, 2005). However, the ARTI-SAN tool used in FLEXICON already supports someaspects of UML 2.0. In Douglas (2004), the authormentions that one can still build complex system usingclass, sequence and state diagrams with UML 1.x. Thus,the Marine application modelled in Version 1.4 can easilybe adapted to UML 2.0 if this is required in the future.Based on a requirements document provided by Rolls-
Royce Marine, the high-speed ship propulsion system was
ARTICLE IN PRESSH.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–9486
modelled using UML. The RT-Profile provided by theARTiSAN RtS tool was also used. Special care was takento produce a model that allows the functionality to beeasily partitioned onto different hardware architectures.When providing systems to different customers, the actualhardware choice (PC-based technology, PLC-based tech-nology, PowerPC-based technology, databus standards,etc.) is often driven by customer preferences. Thus, it isimportant to model the functionality at a level that allowsit to be moved between different hardware platforms.During the development of the model, there were discus-sions with Rolls-Royce Marine on UML specification toallow traceability of requirements, inclusion of informationon Safety Integrity Levels (SIL), sensor types (intelligentand dumb) and hardware information (manufacturers andpart numbers). This information can be passed to othertools such as Excel for requirements traceability manage-ment and through-life cost analysis. The modelling wasdone in a number of stages:
�
The whole UML modelling process starts with theSystem Architecture Diagram, which models the sys-tem’s physical structure and describes the hardwarestructure for the Marine application’s demonstrator.The support for architecture modelling is a particularfeature of the ARTiSAN RtS tool. � Use Case diagrams were used to capture the mainfunctionality of the Marine application. This function-ality includes the various operating modes of the gasturbine engine/waterjet system and also sensor faultdetection and accommodation.
� Class diagrams were created to depict the staticbehaviour and the software structure of the Marineapplication.
� The dynamic behaviour of the Marine application wasmodelled with corresponding State Diagrams, Colla-boration Diagrams and Sequence Diagrams.
� A Concurrency Diagram was used to describe theimplementation with the real-time environment andsystem constraints were modelled to define the timingperformance of the Marine application.
5.3.1. Architecture diagram
The system architecture model plays a critical role in theearly development stages allowing the Systems Engineer toexplore potential architectural solutions using SystemArchitecture Diagrams, and then as a solution emerges,to describe it down to the level of bus, board, etc. TheArchitecture Diagram uses the following components:subsystem, interface device, board, disk, multi-drop bus,and types for defined special characteristics for all theabove components.
The top-level architecture diagram of the Marinedemonstrator in ARTISAN is shown in Fig. 10. Thisdiagram mainly follows the physical structure described inFig. 3. It consists of the following subsystems: MainControl Processor, Backup Control Processor, Bridge
Control Console, Switchboard Control Console, Gateway(Ethernet/CAN), Equipment Health Monitoring, WirelessMonitoring System, and local controllers and I/O systemsfor the gas turbine, gearbox and waterjet, respectively. Thesubsystem ‘bridge control console’ and ‘switchboardcontrol console’ includes two ‘Interface Devices’: ‘OperatorDisplay’ and ‘Operator Input’. The subsystem ‘maincontrol processor’ and ‘backup control processor’ areconnected via a duplex Ethernet network to the Gateway(Ethernet/CAN). The local controllers and their I/Osystems communicate via a triplex CAN network behindthe Ethernet/CAN Gateway. ‘Equipment Health Monitor-ing’ connects with the local I/O subsystems via a separateindustrial Ethernet network.Examples of the internal architecture of the model are
shown in Figs. 11 and 12. In Fig. 11, the local Gas TurbineController is implemented on an Embedded Power PC(EPPC405) running a VxWorks operating system. It hastwo CAN interfaces, one Ethernet and one serial-portinterface. It communicates with the triplex CAN bus forsampling and control of the gas turbine. The communica-tion between the local controller and the main controlprocessor uses the CAN bus and the Ethernet/CANGateway. The smart actuators for waterjet’s steering arecontrolled via embedded controllers which also use CANbus for communication.Fig. 12 gives an example of a pressure sensor. As model
components provided by ARTISAN can only describestandard hardware’s information, stereotypes and tagvalues are designed for special modelling requirements. Astereotype named ‘Sensor Information’ is defined torepresent more information about sensors. It has severaltags, such as ‘Name of Manufacturer’, ‘Part Number’,‘Intelligent’(smart sensor or not), ‘Repetition’(single, du-plex or triplex), ‘MinValue’, ‘MaxValue’ and ‘Type’. Forexample, for a Pressure Sensor monitoring a filter, ‘Filter’,one can specify its ‘Name of Manufactuer ¼ Druck’, ‘PartNumber ¼ 356’, ‘Intelligent ¼ True’, ‘MinValue ¼ 0’,‘MaxValue ¼ 10’ and ‘Repetition ¼ 1’.Class Diagrams are also used to define functionality. Fig.
13 for instance shows the descriptions of classes related tothe four operating modes of the gas turbine and faultdetection functionality.In Fig. 13, the ‘Control and Monitoring of Gas Turbine’
package describes the top-level control of the gas turbine.It includes one main class ‘ ControlGasTurbine’ which isaggregated with classes ‘Start’, ‘Stop’, ‘SpeedControl’ (fornormal operation) and ‘EmergencyTrip’. Detailed beha-viour of these four classes is represented via correspondingstate diagrams. There are another two classes ‘CheckSen-sor’ and ‘SelfTest’.The system ‘Alarms and Warnings’ management pack-
age is shown in Fig. 14. This package has one main class,which includes several subclasses, such as ‘PropulsionTrai-nAlarms’ and ‘LocalControllerAlarms’. It also includesan ‘EMS Alarms’ package that contains alarms related tothe local-level EMS system. A stereotype named ‘Alarm
ARTICLE IN PRESS
Fig. 11. Architecture Diagram of Gas Turbine Control System.
Fig. 12. Architecture Diagram of Gas Turbine Pressure Sensor.
Fig. 10. Architecture Diagram of Waterjet Propulsion System (top-level).
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–94 87
Information’ was also defined to represent informationsuch as ‘REQ’ referring to a specific numbered requirementin the requirements document (this has been used in theFLEXICON Code Generators tools for consistency andtraceability checking against the application requirements)
‘Name’, ‘TrainName’ for different train numbers (a total of5 in this application), and the ‘SIL’ of the alarm function.The SIL data are extracted from ARTISAN using the
FLEXICON Reliability and Through-Life Cost (R&TLC)tool. This tool links ARTISAN and the R&TLC model(based on Excel). Thus, the tool estimates the developmentcost of the system (the SIL level has an impact on thecertification costs). The R&TLC tool is discussed inSection 5.4.
5.3.2. State diagram
State diagrams describe how a system responds to eventsin a manner that is dependent upon its state. Systems thathave a fixed number of states, and that respond to a fixedset of events are called finite state machines (FSMs). UMLhas a rich set of notation elements to describe FSMs. EachState Diagram (and its subdiagrams) models all thepossible state and event sequences permitted for one classof objects in response to external and internal events. Thiscan be seen as a behavioural template for the class that it ismodelling (Artisan, 2002). A State Diagram shows thestates and the transitions between states through which anobject passes during its lifetime, together with its responsesto external events. After creating a State Diagram, theARTiSAN State Machine Generator can be used togenerate the model objects required to implement thesimulation programme for that State Diagram.For the Marine application, the four operational modes
of the gas turbine: start-up, stop, emergency stop andnormal operation (speed control) were modelled with StateDiagrams. Also, the state diagram for sensor faultdetection was modelled for a Sensor class. By using theARTISAN State Machine Generator, the dynamic simula-tion of these state diagrams can be performed forverification purposes. However, in practise, the modellingand simulation of the operational modes of a gas turbineand sensor fault detection are done in more sophisticatedtools like Stateflow/MathWorks or ISaGRAF (using theSFC language). Thus, State Diagrams were considered not
ARTICLE IN PRESS
Fig. 13. Class Diagram of Control and Monitoring Gas Turbine (top-level).
Fig. 14. Tag information of stereotype ‘Alarms Information’.
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–9488
useful to model these requirements for the Marineapplication.
5.3.3. Other diagrams modelled
Apart from state diagrams, other diagrams that alsodepict system dynamics are the Collaboration Diagramand the Sequence Diagram. These both describe the flow ofmessages between objects. Sequence diagrams focus uponthe timing order in which the messages are sent.Collaboration diagrams, on the other hand, focus uponthe relationships between the objects. A Sequence Diagramshows the interactions which occur between the objects inthe Use Case. It is thus a graphical description of a UseCase. The diagram comprises statements, objects andstimuli. A Collaboration Diagram models the structuraldimension of a scenario by graphically illustrating the
interactions between actors and objects. It provides analternative representation of a Sequence Diagram, each onemodelling a different execution thread (or ‘scenario’)through a Use Case by showing the flow or sequence ofmessages between associated objects. The Use Cases,‘Automatic Operation Mode’ and ‘Start-up of GasTurbine’, were modelled using both Collaboration Dia-grams and Sequence Diagrams. Timing performance wasalso analysed and attached to the sequence diagram. AConstraints Model was used to define the constraintsapplicable to a system. Three types of constraints related tothe Marine application were represented: timing, perfor-mance and reliability. Although, it was useful to explore allof these diagrams to model the requirements, thesediagrams are not further used to interact with theFLEXICON toolset.
ARTICLE IN PRESSH.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–94 89
Concurrency Modelling was used to take a set of objectsimplementing the required functionality (using ClassDiagrams) of the system and to schedule them so thatthe system meets its performance goals given the targethardware (System Architecture Diagram). A ConcurrencyDiagram represents a multi-tasking model. Thus, in theConcurrency Diagram that was created, the objects aremapped to their corresponding tasks. These tasks are thenmapped to the hardware devices created in the ArchitectureDiagram. The Concurrent Diagram has been used in theFLEXICON Code Generator tools.
5.3.4. Fault injection co-simulation
Referring back to the overall vision described in Fig. 1,integration of ARTISAN allows the control and plantsimulations developed in ISaGRAF and Simulink to beconnected to the architecture model of the system describedin UML. To demonstrate this, faults were injected into theSimulink model of the system (using a specially developedGUI as shown in Fig. 9). These are detected using faultdetection blocks in Simulink. The client in ARTISAN isshown in Fig. 15(a). This window shows that ARTISANhas successfully received the fault information fromSimulink and recorded this as a Short-circuit in the‘Combustor inlet temperature’ Interface Device withinARTISAN. The failed components are automaticallyhighlighted within the hardware architecture model.
The information can also be displayed on a faultinspector mimic as shown in Fig. 15(b). Here, the fact thatthere has been a short-circuit failure in the ‘Combustorinlet temperature Sensor’ is also recorded. Additionally, ared circle is given to warn that a failure has occurred onthat particular sensor and the date and time of the failure isrecorded. This information is logged in a file and used torecord the results of fault injection testing programmes. Itis also possible to expand this figure to locate the faultmore accurately inside a gas turbine engine picture.
Fig. 15. Fault information (a) from ARTIS
5.4. Co-simulation with excel reliability and through-life
cost models
Although Excel can be used to record the occurrences offailures and provides a useful feature for running testcampaigns, the primary role of Excel in the environmentis to support reliability and through-life cost modelling.A R&TLC tool that is part of the FLEXICON toolsetwas developed. This tool possesses a CORBA interfacethat allows calculation of system reliability figuresthrough extraction of data from the design tools. Also,this tool calculates automatically the cost of the systemas the system’s architecture is defined in UML andcontrol functionality is defined in Simulink and ISaGRAF.For instance, information on SIL and sensor types(intelligent and dumb) has been built into the UMLmodel (Class Diagrams and Architecture Diagrams,respectively) as described in the previous section. Addi-tionally, the degree of complexity of the control systemcan be extracted from the Simulink and ISaGRAFmodels by assessing the number of blocks/steps used. Thisallows the impacts on development and maintainabi-lity costs (and hence through-life costs) to be esti-mated through on-line extraction of information fromthe ARTISAN and Simulink tools via the co-simulation.This also allows systems engineers to rapidly assess newdesigns or modification of current designs with respect tothe through-life cost. This is particular useful whenconsidering Total Care Package contracts and rapidproduction of figures for ‘7 day proposal support’ inresponse to bids.The form of the functional and hardware reliability
models used to calculate system reliability/availability andthrough-life costing from the functional unavailability isgiven in Fig. 16(a) and (b). These take architectureredundancy level and complexity information from theUML, Simulink and ISaGRAF models and combine this
AN Client; (b) Fault Inspector Mimic.
ARTICLE IN PRESS
(a) (b)
Fig. 16. (a) Functional and (b) hardware reliability models.
Fig. 17. Hardware reliability model data input form.
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–9490
with information describing the boards and equipmentused, e.g. failure rates, costs, etc.
Drop down menus as shown in Fig. 17 are used to inputdata such as the usage and cost of unavailability of thepropulsion system. Within the spreadsheet it is possible forthe user to switch between forms and add new items to theequipment library.
5.4.1. R&TLC tool
This Section gives a simple example of how the reliability(see Fig. 18) and through-life models can be used to aid
decision-making in the design and development of acontrol system. Components details are stored in aspreadsheet including failure rate and cost information.This is combined with the expected usage data andnumbers of components used taken from the architecturemodel (UML) to calculate the total unreliability.The Control System tab of the form (see Fig. 19(a)) is
used to input data associated with the general design andintended use of the control system. This also features aplace to add the name of the particular system beingmodelled or assessed. This name is attached to the outputs
ARTICLE IN PRESS
Fig. 18. Hardware reliability model example.
Fig. 19. Marine through-life cost input form: (a) control system, (b) maintenance, (c) disposal.
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–94 91
form to the model to allow the user to distinguish betweendifferent trials of various systems. The Degree of Automa-
tion is extracted from the Simulink and ISaGRAF tools,and the Level of Safety Justification from the ARTISANtool. The Maintenance tab of the input form contains theinput parameters associated with the maintenance of the
control system. The Predictive Maintenance can be high,medium or low; the Maintenance Regime can be on-boardor shore based; and the level of Repair and Support
Network can be high, medium or low—this is shown inFig. 19(b). The Disposal tab contains the input parameterassociated with the disposal of the control system
ARTICLE IN PRESS
Fig. 20. Example of summary bar chart for marine Through-Life Cost tool.
H.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–9492
(destroyed, recycled or sale to third party). The disposaltab is shown in Fig. 19(c). Once the parameter values havebeen extracted from the COTS tools (mainly for theControl System tab) and the other parameters are selectedon the other two tabs, the user presses the Calculate buttonand the information in the form is loaded into the R&TLCmodel.
5.4.2. Outputs from the model
The outputs from the Marine through-life cost model aretables and graphs showing the cost of the various stagesand activities. The main output page displays the cost (inthousands of pounds) for each of the through-life activitiessplit into the acquisition, operational and disposal stages.A summary of the cost for each stage is also given. Theoutput form associated with this page also allows the userto select bar graphs for the individual stages as well as asummary bar graph and pie chart for the entire project.The pie chart can be particularly useful as this gives aneasily interpreted display of the proportional contributionof each stage. An example of the summary bar chart isshown in Fig. 20.
6. Related work
A number of projects are investigating some of theintegrating technologies being used in FLEXICON.
In Dias, Teixeira, Teixeira, Becker, and Pereira (2001),an approach called MOSYS is described. MOSYS is amethodology for developing distributed real-time applica-tions based on distributed autonomous objects. Theapproach provides a method for automatic identificationof possible design objects architectures and includes
testability support during the design phase. MOSYS alsooffers support for automatic code generation for a real-time operating system. Although this approach is targetedat distributed real-time applications its emphasis is on aparticular phase in the development life-cycle—‘best fittedarchitecture’.Paunicka, Corman, and Mendel (2001) describe an Open
Control Platform (OCP), which facilitates the transitioningof control designs to embedded targets. The OCP is aCORBA-based solution for unmanned autonomous vehicle(UAV) control algorithms. The OCP contains a ControlApplication Programming Interface (API), thus the controldesigner takes the design generated by Simulink and usesthe Control API Front End Tool to enhance the designwith additional Quality of Service (QoS) Information (e.g.worse case execution times, allowable rates of execution,scheduling type, physical layout and data types). Then, theControl API Front End tool generates an XML represen-tation of the system. This XML description of the system isprovided as an input to the Control API Back End toolthat generates the OCP component framework. Finally, thedesigner adds Real-Time Workshop generated code(C++) to OCP’s component framework. This workdepends totally on the Real-Time Workshop to generatecode. However, using a descriptive language such as XMLallows non-functional information to be added.HIDOORS is an integrated development environment
for embedded distributed real-time systems and it is basedon the Java programming language. The goal of HI-DOORS is to provide the full functionality of the Javalanguage for the development of distributed, real-time andsafety-critical systems and to provide a set of tools thatsupport modelling, analysis and proof of correctness of
ARTICLE IN PRESSH.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–94 93
systems developed in Java. This environment will cover allthe life-cycle of real-time software development usingextensions to existing tools (UML modelling, Javacompiler, Java Virtual Machine and a worst-case executiontime analysis tool) (Ventura, Siebert, Walter, & Hunt,2002).
A Boeing project, Open System Architecture-Condition-Based Maintenance (Boeing, 2002) uses the real-timemiddleware (RT-CORBA) to transfer data between com-puters and XML/HTTP for user display. RT-CORBA isused for high-level object semantics and XML for low-leveltext semantics. Java Servlet (Web Server: Tom Cat) is usedto extract RT-CORBA data and convert it to XML.
The Integrated Modelling for Analysis and Generationof Embedded Software (IMAGES) project from theCarnegie Mellon University (CMU, 2002) has the goal toimprove productivity of developing validated software forembedded systems through simultaneous and consistentmulti-view modelling and meta-modelling support. It willcreate a modelling framework, comprising extensiblenotation, analysis engines, tools and services for integra-tion, analysis and generation of embedded software.
Another project is the Model-Based Integration ofEmbedded Software (MoBIES) at the University ofCalifornia at Berkeley (UCB, 2002). This project is focusedon the design of process-oriented components and theirruntime environments for real-time embedded systems.Finally, in Krus (2002), the author presents a co-simulationof a wheel loader using a Simulink model, a HOPSANmodel and a model in Adams. HOPSAN is a simulationpackage for fluid power technology and Adams is a tool forsimulation of three-dimensional mechanical systems.
Although prototyping and analysis of systems is a veryactive area of research, FLEXICON is different in that itaims to reduce the development life-cycle and implementa-tion cost for distributed control systems. FLEXICON willprovide a set of tools for Marine, Aerospace andAutomotive applications (FLEXICON MAA), which willallow the integration of COTS tools (via co-simulation andwith HIL) for the design and development of theseapplications. Also, the tools will allow analysis of controlsystem performance, fault tolerance availability andthrough-life cost. FLEXICON uses open standards suchas OPC, IEEE 1451 and other standards like UML, IEC61131-3, CORBA and recently NDDS. The COTS toolsbeing integrated are ISaGRAF, Simulink, ARTISAN RtSand Excel.
7. Concluding remarks and future work
In this paper, a flexible multi-disciplinary co-simulationenvironment has been described that has been developedfor analysis and integration of distributed control systems.The FLEXICON toolset is applicable across a wide rangeof distributed real-time, safety-critical systems. Applica-tions include aerospace, marine, automotive and a range ofprocess control applications through the interface with
ISaGRAF for IEC 61131-3 programming of PLC-basedsystems. It should be noted that the methodology of howthe tools are used is not prescriptive. For instance, it will bedifficult to change the development process model of Rolls-Royce Marine or any other company. Thus, the FLEX-ICON toolset is based on the V-model that is well acceptedand widely used for the development of an application.Also, it is very similar to the process model used at Rolls-Royce. The interfaces developed for the co-simulation areflexible allowing engineers to perform whatever studiesthey wish.In the case of the Marine application described in this
paper, Rolls-Royce Marine provided a requirementsdocument and also a Simulink model which was extendedto meet these requirements. As mentioned in the paper, theSimulink model only accounts for 20% of the require-ments. Thus, using other COTS tools, models were createdto fully comply with these requirements. For instance, thesupervisory control modes driven by a Captain’s HMI(start-up, normal operation, normal stop and emergencystop) were implemented in a SFC diagram using theISaGRAF tool. This SFC is used in co-simulation tocontrol the gas turbine engine/waterjet model in Simulink.A GUI in Simulink was also implemented to allow faultinjection to create a range of open- and short-circuitfailures in sensors. The results of these fault injectionexperiments can be logged in a file or used to indicatesensor failures graphically. Redundancy was designed in aSystem Architecture Diagram using the ARTISAN tool.Critical failures such as an overspeed can also be simulatedand the correct response (emergency shutdown of the gasturbine engine) can be validated. Finally, informationabout the system control complexity can be extracted fromthe ISaGRAF and Simulink tools, along with physicalinformation on the hardware architecture (componentsused and their arrangement to create redundancy) andfunctional information such as the safety integrity levels ofdifferent functions to be used in the reliability and through-life cost modelling tools in Excel. This provides a powerfulmeans of assessing the viability of systems for Total CarePackage contracts and also supporting rapid production ofdata for ‘7 Day Proposal’ generation. In order to generatecode for the full application, Code Generation tools havebeen also implemented in the project. These tools are notreported in this paper. Currently, a demonstrator that willallow the performance evaluation of the tools is beingconstructed.
Acknowledgements
The authors gratefully acknowledge the financial sup-port of the European Union’s Information and ScienceTechnologies programme for the FLEXICON projectIST-2001-37269, Rolls-Royce plc., the DTI and theLoCostUCAV project. Additionally, the authors gratefullyacknowledge the support provided by ARTISAN, Borlandand WindRiver.
ARTICLE IN PRESSH.A. Thompson et al. / Control Engineering Practice 15 (2007) 77–9494
References
Artisan. (2002). Manual of ARTISAN real-time studio. Version 4.2,
ARTISAN Software tools.
Boeing. (2002). Open system architecture-condition-based maintenance.
http://www.osacbm.org/Documents/milestones/milestone10/Boein-
g_OSACBM_Milestone10_ver3.pdf; Access date: 11/10/2002.
Borland. (2002). C++ Builder 6 Developer’s guide. The Borland Software
Corporation.
Browne, A. R., Bass, J. M., & Fleming, P. J. (1997). A building-block
approach to the temporal modelling of control software. In Proceed-
ings of the fourth IFAC workshop on algorithms and architectures for
real-time control, AARTC 97, Portugal, pp. 433–438.
Cashman, M. (2001). A basic CORBA application. http://www.tempor
aldoorway.com/programming/cbuilder/multitier/basiccorba.htm.
CMU (2002). The integrated modeling for analysis and generation of
embedded software (IMAGES). http://www.rl.af.mil/tech/programs/
MoBIES/Carnegie_Mellon_U.html; Access date: 11/10/2002.
Dias, O. P., Teixeira, I. M., Teixeira, J. P., Becker, L. B., & Pereira, C. E.
(2001). On identifying and evaluating object architectures for real-time
applications. Control Engineering Practice, 9, 403–409.
Douglas, B. P. (2004). What’s new in UML 2.0? IEE Electronics Sector,
published on 1 December 2004.
Isagraf. (2002). ISaGRAF Enhanced-Workbench (2.4). AlterSys.
Krus, P. (2002). System modelling and simulation. http://www.machine.ikp.
liu.se/edu/post/multidomain/SMSkurs1.pdf; Access date: 11/10/2002.
Lewis, R.W. (1998). Programming industrial control systems using IEC
1131-3’’ (revised ed.). IEE Publications.
Li, M., & Qi, M. (2004). Leveraging legacy codes to distributed problem-
solving environments: a web services approach. Software-Practice and
Experience, 34, 1297–1309 (Wiley InterScience).
Newman, A. J. (2005). Hardware co-simulation of a tailless, thrust
vectoring unmanned aerial vehicle. M.E dissertation, University of
Sheffield, submitted for publication.
OMG-CORBA. (2005). http://www.omg.org/gettingstarted/corbafaq.htm;
Access date: 06/06/05.
OMG-RT Profile. (2003). Draft available specification, ‘UML profile for
schedulability, performance, and time specification’. http://www.omg.
org; ptc/2003-03-02.
OMG-UML. (2005). http://www.uml.org/; Access date: 07/06/05.
Paunicka, J. L., Corman, D. E., Mendel, B. R. (2001). A CORBA-based
middleware solution for UAVs. In The fourth IEEE international
symposium on object-oriented real-time distributed computing, ISORC
2001, 2–4 May (pp. 261–267). Magdeburg, Germany: IEEE Computer
Society.
Ramos-Hernandez, D. N., Fleming, P. J., & Bass, J. M. (2005). A novel
object-oriented environment for distributed process control systems.
Journal of Control Engineering Practice, 13(2), 213–230.
Segue Software. (2003). A CORBA primer—CORBA white paper. http://
cgi.omg.org/library/seguecorba.pdf; Access date: 06/03/03.
Stateflow. (2002). Stateflow and stateflow coder for complex logic and state
diagram modelling. User’s Guide Version 5.0. The MathWorks Inc.
Stewart, P. G., & Fleming, P. J. (2001). The response surface methodology
for real-time distributed simulation. In Proceedings of the IFAC
conference on new technologies for computer control, Hong Kong
(pp. 128–133).
Tari, Z., & Bukhres, O. (2001). Fundamentals of distributed object
systems. In A. Y. Zomaya (Ed.), The CORBA perspective. Wiley series
of parallel and distributed computing. USA: Wiley.
Thompson, H. A., & Ramos-Hernandez, D. N. (2004). A flexible control
systems development and integration environment for distributed
control. In Proceedings of the sixth Portuguese conference on automatic
control, Controlo 2004, 7–9 June, Faro, Portugal.
Thompson, H. A., Ramos-Hernandez, D. N., Cartledge, K., Fortune, J.,
& Brown, A. (2003). A flexible control systems development and
integration environment for distributed ship control. In 13th interna-
tional ship control systems symposium (SCCS), 7–9 April, Orlando,
USA.
Thompson, H. A., Ramos-Hernandez, D. N., Fu, J., Jiang, L., Nui, J., &
Choi, I., et al. (2004). FLEXICON co-simulation environment for the
marine application. In Proceedings sixth Portuguese conference on
automatic control, Controlo 2004, 7–9 June, Faro, Portugal.
UCB. (2002). Model-based integration of embedded software. http://
ptolemy.eecs.berkeley.edu/projects/mobies/; Access date: 11/10/2002.
Ventura, J., Siebert, F., Walter, A., & Hunt, J. (2002). HIDOORS—
A high integrity distributed deterministic Java environment. In
Proceedings of the seventh IEEE International workshop on object-
oriented real-time dependable systems (WORDS 2002), 7–9 January
(pp. 113–118). San Diego, CA: IEEE Computer Society.
Further reading
Simulink. (2002). Simulink, model based and system based design. Using
Simulink version 5.0. The MathWorks Inc.
