| Date post: | 09-Nov-2018 |
| Category: |
Documents |
| Upload: | truongtram |
| View: | 220 times |
| Download: | 0 times |
UNIVERSIDADE FEDERAL DE SANTA CATARINA
CURSO DE ENGENHARIA DE CONTROLE E AUTOMAÇÃO
Profibus Communication Interface between
Test Simulators and Control Systems on Marine Vessels
Monografia submetida à Universidade Federal de Santa Catarina como requisito para a aprovação da disciplina:
DAS 5511 Projeto de Fim de Curso
Sacha Geyger Boff
Florianópolis, Setembro de 2007
Profibus Communication Interface between Test
Simulators and Control Systems on Marine Vessels
Sacha Geyger Boff
Esta monografia foi julgada no contexto da disciplina DAS 5511: Projeto de Fim de Curso
e aprovada na sua forma final pelo Curso de Engenharia de Controle e Automação
Banca Examinadora:
Prof. Dr. -Ing. Tor Arne Johansen Orientador Empresa
Prof. Agustinho Plucenio Orientador do Curso
Prof. Augusto Humberto Bruciapaglia Responsável pela disciplina
Prof. Julio Elias Normey-Rico, Avaliador
Renato Carlo Zacchello Leal, Debatedor
Tiago Ferreira, Debatedor
Acknowledgments
I would like to thank my family for all the love and support during all these
years, you are the persons that I take as an example to follow, you are my support
and my strength.
For the realization of this project I would like to show all my appreciation to
Marine Cybernetics, to the managers for the opportunity, and to my work colleagues,
these wonderful persons that I had the chance to share great learning and delight
moments. My special thanks to my supervisor Professor Tor Arne Johansen for the
orientation; to Sonja Tennøy who would always help and instruct me; to Matthias
Schellhase, Torleiv Sundre and Gjermund Tomta, that would assist me in some
tasks. I cannot forget to mention the 2 persons that help me in getting the internship,
Professor Eduardo Camponogara and Hans Petter Bieker. A special thanks to my
Brazilian supervisor Professor Agustinho Plucenio, who was a great tutor for a couple
of years. Thanks for the Brazilian National Petroleum Agency, for the 2 years
internship in the Project PRH-34.
I would also like to show my gratitude to my university colleague Carlos Vieira
e Vieira, who was always very patient and helpful with me during this project. I must
not forget to cite all my wonderful university colleagues, which I had great learning
lessons during the university years. You are not just my classmates, but you are all
very special friends.
I would like to show my gratitude to all my professors, great persons, brilliant
researchers, examples to be followed!
For all these persons, and some others that I might have not mentioned, I
want to say thank you so much! Thank you for all you have taught me. For you, I
dedicate this great poem from Guillaume Apollinaire:
“Come to the edge. We might fall. Come to the edge. It's too high!
And they came
and he pushed
and they flew ...”
ii
Resumo
O presente trabalho mostra a implementação de uma interface de
comunicação para emular o funcionamento de dispositivos escravos em uma rede
Profibus a fim de integrar o simulador CyberSea com sistemas de controle em uma
embarcação. A simulação tem como objetivos detectar falhas e verificar
procedimentos operacionais no sistema de controle em desenvolvimento.
Visto que o cenário de testes possui 4 controladores CLP, a utilização de uma
rede de computadores foi necessária para troca de dados com o computador que
roda a simulação. A troca de mensagem (datagrama) se dará via UDP/IP.
A interface de comunicação e o serviço de entrega de datagramas foi
implementado em três blocos funcionais a partir de S-functions do Simulink, usando
como linguagens de programação C e C++. Para a emulação dos dispositivos
Profibus escravos utilizou-se o hardware SimbaPro que é capaz de simular 125
dispositivos Profibus DP/PA.
O projeto envolve diversas tecnologias presentes na indústria, e aparece
como uma ferramenta para interfaceamento de comunicação entre simuladores e
sistemas de controle bastante útil e moderna. A implementação do código levou em
vista a generalidade de funções, o que permite usar os blocos em outros projetos
que envolvam a mesma tecnologia.
O trabalho foi desenvolvido durante 5 meses na empresa Marine Cybernetics,
na Noruega, no ano de 2007.
iii
Abstract
The present project illustrates the implementation of a communication
interface that will emulate slave devices’ functionalities in a Profibus network in order
to integrate the CyberSea simulator with a vessel’s control system. The objective of
the simulation is to detect failures and to verify operational procedures in the control
system being developed.
As the test scenario has 4 PLC controllers, a computer network was
necessary in order to change data with the simulator computer. The message’s
exchange (datagrams) will be realized via UDP/IP.
The communication interface and the datagram service was implemented in 3
functional blocks through a Simulink S-function, by means of C and C++
programming languages. The SimbaPro hardware was used for the emulation of the
Profibus slaves devices. It can simulate up to 125 Profibus DP/PA slaves.
The project deals with several technologies used in marine vessels industry,
and it comes as a very useful and modern communication interface tool between
simulators and control systems. The software code implementation was programmed
taking into consideration the generalization of the functions, allowing for the
reutilization of the blocks in other projects that employ the same technology.
The project was developed during 5 months at the Company Marine
Cybernetics, in Norway, in the year 2007.
iv
Resumo estendido
Devido aos modernos e complexos sistemas de controle usados em
embarcações, um novo método de testes e verificação se tornou necessário. A
tecnologia de simulação Hardware-in-the-Loop (HIL) vem ao encontro desta nova
exigência da indústria, de maneira a verificar a segurança e perfomance do sistema,
e eventualmente criar um novo standart para certificações.
O objetivo da simulação HIL é testar o sistema de controle tendo em vista
requisitos funcionais e de segurança. Para isso conecta-se o simulador ao sistema
de controle da embarcação, testando-o com condições reais de operação. A maior
vantagem deste tipo de testes é detectar em estágios iniciais erros de software,
configuração e verificar o funcionamento dos parâmetros de falhas. A empresa
desenvolvedora do sistema de controle pode então corrigir os erros e
inconsistências, tornando o sistema mais confiável.
A embarcação a que o projeto se destina é de perfuração, sendo
normalmente usada para fins exploratórios em novos poços de óleo e gás em águas
profundas. O sistema de controle que será testado na embarcação é o sistema de
gerenciamento de potência (PMS), este tem como finalidade monitorar e controlar o
sistema de propulsão elétrica a diesel. Ele seleciona os geradores que devem ser
ligados, tendo em vista a demanda de carga dos propulsores, bombas, entre outros.
Neste trabalho será implementado uma ferramenta/módulo para
interfaceamento de comunicação Profibus entre o simulador CyberSea e o sistema
de controle da embarcação, de maneira que durante a execução do teste o sistema
não experimente nenhuma diferença qualitativa quanto à integração ao sistema real.
O PMS é parte integrante do sistema de controle IAS – Sistema Integrado de
Automação. Cada sala de motor possui um CLP S7-400 da Siemens instalado
realizando funções do PMS e do IAS. O controlador é composto de um rack
equipado com uma CPU e diversos cartões, estes possuem interface Simocode e
I/O remotas.
A unidade de perfuração possui 8 geradores a diesel, os quais são reunidos
em 4 grupos de 2 geradores, cada grupo formando um sistema de potência
v
autônomo. Uso extensivo de I/O remotas e simocode via Profibus serão usadas para
conectar equipamentos ao controle PMS. A comunicação do relé de proteção do
gerador ao sistema PMS se dará através da tecnologia Profibus DP.
A interface de comunicação Profibus é programada em S-Funcion, a qual é
uma linguagem de programação descritiva presente em um bloco do Simulink, e
escrita em linguagem C++.
O PMS da embarcação consiste de 4 CLPs, cada qual com 3 mestres (1
barramento para cada mestre); o primeiro barramento consiste de um mestre ligado
ao dispositivo escravo o qual é composto de um quadro de distribuição com 8 réles
de proteção multifuncionais; os outros 2 barramentos incluem um mestre conectado
ao escravo de I/O remota. Cada relé possuiu aproximadamente 25 sinais, e as I/O
remotas têm 100 sinais, portanto o projeto contará com 400 sinais para cada CLP.
Os CLPs serão conectados via Profibus DP a um computador (computador de
I/O remota) que simulará os dispositivos escravos; os verdadeiros escravos serão
removidos do sistema a fim de que a simulação aconteça. Cada computador de I/O
remota simula o funcionamento de escravos através do módulo SimbaSys da
Siemens, o qual pode simular até 125 escravos Profibus DP/PA por canal.
A rede de computadores será composta por 4 computadores de I/O remota
conectados através de um switch ao simulador CyberSea a fim de trocar dados via
UDP. O simulador CyberSea possui um computador simulador e um computador
administrador; a comunicação entre eles é por TCP/IP e RPC.
O ambiente de simulção é o Matlab e Simulink que provaram ser plataformas
eficientes e flexíveis para aplicações em tempo real.
Foram desenvolvidos 3 blocos funcionais no Simulink através das S-
Functions. O bloco ‘UDPsend’ envia datagramas a um determinado tempo de
amostragem ao computador de destino através de uma dada porta. O block
‘UDPreceive’ recebe datagramas de um computador, com uma determinada taxa de
amostragem e através de uma dada porta. O bloco ‘pbusSlave’ recebe e envia
dados de/para uma unidade de simulação de escravos Profibus DP/PA compatível.
O bloco ‘pbusSlave’ usa 3 bibliotecas: “SimbaKern.dll” possui funções
referentes à aplicação no módulo SimbaSys, que permitem acesso de outras
aplicações a este módulo; “SimbaProLib.dll” conta com 2 funcionalidades principais,
vi
leitura de um arquivo XML (usando a biblioteca externa Xerces C++) contendo os
dados de cada sinal e tem funcinalidade de inicialização do programa SimbaPro,
leitura e escrita aos escravos e finalização do programa; e a “CyberSeaMsgDLL.dll”
mostra mensagens de erros e depuração do programa.
Foram realizados testes para validação da aplicação, tais testes foram
finalizados com sucesso, os blocos funcionais estão corretamente integrados à
biblioteca CyberSea. A taxa de comunicação UDP para o máximo número de sinais
a serem transmitidos é menor que 10μs e está devidamente abaixo do tempo de
ciclo requiridos pelo simulador CyberSea, que é de 500ms.
A implementação do código dos blocos funcionais levou em vista a
generalidade de funções, o que permite usar os blocos em outros projetos que
envolvam a mesma tecnologia.
O trabalho abrange diversas áreas do curso de engenharia de controle e
automação, dentre eles redes industriais, controle, simulação de sistemas em tempo
real, satisfazendo os requisitos da disciplina de fim de curso. O trabalho tem como
resultado reais soluções de software para interfaceamento de comunicação entre
simuladores e sistemas de controle de diversos fornecedores, satisfazendo à
necessidade de uma ferramenta de interface comum Profibus.
Este projeto foi desenvolvido durante 5 meses, no ano de 2007, na empresa
Marine Cybernetics, sediada na Noruega.
vii
Glossary
ACKNOWLEDGMENTS ...................................................................................................... II
RESUMO............................................................................................................................. III
ABSTRACT .........................................................................................................................IV
RESUMO ESTENDIDO .......................................................................................................V
GLOSSARY.......................................................................................................................VIII
LIST OF FIGURES.............................................................................................................XII
LIST OF TABLES..............................................................................................................XIII
SYMBOLS ........................................................................................................................XIV
CHAPTER 1: INTRODUCTION...........................................................................................1
1.1: Objectives......................................................................................................................2
1.2: Structure ........................................................................................................................3
1.3: About the Company Marine Cybernetics AS................................................................4
CHAPTER 2: BACKGROUND.............................................................................................6
2.1: Profibus..........................................................................................................................6
2.1.1: Standard................................................................................................................7
2.1.2: Profibus in the ISO/OSI Model..............................................................................8
2.1.3: Application Areas of Profibus................................................................................9
2.1.4: Transmission Technologies ................................................................................11
2.1.5: Communication Protocol DP...............................................................................11
2.1.6: Addressing with Slot and Index ..........................................................................15
viii
2.1.7: Commissioning....................................................................................................17
2.1.8: Profibus GSD File ...............................................................................................17
2.2: Computer Networking .................................................................................................18
2.2.1: TCP/IP Model......................................................................................................18
2.2.2: User Datagram Protocol (UDP)..........................................................................19
2.3: Power Management in Marine Vessels......................................................................20
2.3.1: Control System....................................................................................................20
2.3.2: Dynamic positioning............................................................................................21
2.3.3: Electric Propulsion Systems ...............................................................................22
2.3.4: Power Management Systems (PMS).................................................................23
CHAPTER 3: SIMULATION FOR VESSEL TESTING .....................................................26
3.1: HIL Testing in Modern Ships.......................................................................................27
3.2: HIL Simulator...............................................................................................................28
3.3: Interface.......................................................................................................................29
3.4: Fault, Failure and Failure Mode ..................................................................................29
3.5: CyberSea Simulator ....................................................................................................31
CHAPTER 4: CASE STUDY..............................................................................................34
4.1: The Drilling Vessel.......................................................................................................34
4.2: PMS of the Drilling Unit ...............................................................................................36
4.3: Plant Simulator Requirements ....................................................................................37
4.3.1: Interfacing to the Control Computer System......................................................38
4.3.2: Failure modes......................................................................................................38
4.3.3: Monitoring, Data Logging and Test Scenario Scheduling..................................39
CHAPTER 5: IMPLEMENTATION AND VALIDATION ....................................................40
5.1: Overview of the Project ...............................................................................................40
5.2: Simulation Environment ..............................................................................................41
5.3: Profibus DP Communication Interface .......................................................................42
ix
5.3.1: S-function ............................................................................................................43
5.3.2: SIMBApro............................................................................................................44
5.3.3: XML .....................................................................................................................45
5.4: Network Data Exchange Using UDP..........................................................................47
5.4.1: The UDP Simulink Diagram for the CyberSea Simulator ..................................48
5.4.2: The UDP Simulink Diagram for the Remote I/O Computer ...............................50
5.5: Validation of the Modules............................................................................................51
5.5.1: Simulator Test .....................................................................................................52
5.5.2: Self-Test ..............................................................................................................53
5.5.3: Results of Testing Phase....................................................................................54
CHAPTER 6: PROGRAMMING OF THE S-FUNCTION BLOCKS..................................56
6.1: Simulation Stages .......................................................................................................56
6.2: S-Function Callback Methods.....................................................................................57
6.3: UDP Send Block..........................................................................................................59
6.4: UDP Receive Block.....................................................................................................60
6.5: pbusSlave Block..........................................................................................................61
6.6: Implementation of SimbaProLib Library......................................................................63
6.6.1: External Dependencies.......................................................................................63
6.6.2: Internal Dependencies ........................................................................................64
6.6.3: Library Architecture .............................................................................................64
CHAPTER 7: CONCLUSIONS AND PERSPECTIVES....................................................68
BIBLIOGRAPHY:................................................................................................................70
APPENDIX A: REQUIREMENTS SPECIFICATION FOR CYBERSEA PROFIBUS
DP/PA SLAVE MODULE ...................................................................................................72
A.1: Block inputs, outputs, and masked parameters.........................................................72
A.1.1: Input signals........................................................................................................72
A.1.2: Output signals.....................................................................................................72
A.1.3: Masked Parameters ...........................................................................................73
x
A.1.4: Parameters of the XML file read in “SimbaProLib.dll”........................................74
A.1.5: Inherent failure modes........................................................................................74
A.1.6: Warning/error messages....................................................................................74
A.2: Functional requirements .............................................................................................75
A.3: Test requirements.......................................................................................................76
APPENDIX B: REQUIREMENTS SPECIFICATION FOR UDP MODULES ...................78
B.1 UDP receive block ..................................................................................................78
B.1.1 Masked parameters..........................................................................................78
B.1.2 Output signals...................................................................................................79
B.1.3 Failure modes...................................................................................................79
B.1.4 Warning/Error messages .................................................................................79
B.1.5 Comments on implementation .........................................................................79
B.2 UDP Send Block .....................................................................................................79
B.2.1 Input signals......................................................................................................80
B.2.2 Masked parameters..........................................................................................80
B.2.3 Failure modes...................................................................................................80
B.2.4 Warning/error messages..................................................................................80
B.2.5 Comments ........................................................................................................81
B.3 Functional requirements .........................................................................................81
B.4 Test requirements ...................................................................................................82
xi
List of Figures
Figure 1: Simplified overview of the project .................................................................3
Figure 2: Application areas of Profibus within the production pyramid ......................10
Figure 3: Profibus DP mono-master system..............................................................14
Figure 4: Addressing with slot and index...................................................................16
Figure 5: PMS configuration ......................................................................................24
Figure 6: Control system development according to the V-cycle...............................27
Figure 7: Normal Operation of a Vessel ....................................................................33
Figure 8: Factory Acceptance Test............................................................................33
Figure 9: Dock and Sea trials ....................................................................................33
Figure 10: Drilling vessel ...........................................................................................35
Figure 11: Vessel’s sub-systems including interface to the CyberSea Simulator ......35
Figure 12: PMS Diagram with Profibus communication interface..............................37
Figure 13: PMS configuration ....................................................................................38
Figure 14: Project Implementation.............................................................................41
Figure 15: Modules of the Profibus DP slave block ...................................................42
Figure 16: SimbaPro Slave configuration ..................................................................45
Figure 17: Distribution of the Simulation Application .................................................48
Figure 18: Simulink diagram for the CyberSea Simulator..........................................49
Figure 19: Simulink diagram for the remote I/O computers .......................................50
Figure 20: Simulator’s interface for Simulator Test....................................................54
Figure 21: Stages of a Simulink simulation................................................................57
Figure 22: SimbaProLib.dll UML diagram..................................................................67
xii
List of Tables
Table 1: Structure of IEC 61158 ..................................................................................7
Table 2: The fieldbuses in IEC 61158 .........................................................................8
Table 3: The OSI reference model ..............................................................................9
Table 4: Requirements for communication systems..................................................10
Table 5: Overview of the DP-V0 ................................................................................15
Table 6: Typical failure modes within the different subsystems.................................30
Table 7: Masked parameters for pbusSlave block.....................................................73
Table 8: XML initialization file parameters .................................................................74
Table 9: Masked parameters for UDP receive block .................................................78
Table 10: Masked parameters for UDP send block ...................................................80
xiii
Symbols
ASIC User Specific Circuit
AS Actuator Sensor
CPU Central Processing Unit
CRC Cyclic Redundancy Check
DG Diesel Generator
DLL Dynamic Link Library
DP Dynamic Positioning
DP Decentralized Periphery (Profibus)
DPM Decentralized Periphery Master
DOM Document Object Model
DTD Document Type Definition
FAT Factory Acceptance Tests
FMEA Failure Mode and Effects Analysis
FMS Fieldbus Message Specification
GSD General Station Description
HIL Hardware-In-the-Loop
HMI Human Machine Interface
HW Hardware
IAS Integrated Automation System
IAT Import Address Table
IEC International Electro technical Commission
IP Internet Protocol
IPC Inter-Process Communication
xiv
I/O Input/Output
ISO International Standard Organization
LAN Local Area Network
MBP Manchester coded Bus Powered
MEX Matlab Executable
OS Operating System
PA Process Automation
PC Personal Computer
PCI Peripheral Component Interconnect
PLC Programmable Logic Controller
PMS Power Management System
RPC Remote Procedure Call
SW Software
TCP Transmission Control Protocol
UDP User Datagram Protocol
UPS Uninterrupted Power Supply
UML Unified Modeling Language
XML eXtensible Markup Language
xv
Chapter 1: Introduction
As modern machinery systems for marine vessels become increasingly
complex, there is a need to develop new and improved methods for testing and
verification. This is important in order to give the vessel owner confidence in the
acquired functionality, and performance assurance to vessel contractors, and
eventually it may set a new standard for certification. In this context, testing by
Hardware-in-the-Loop (HIL) simulation of the control and monitoring system has
recently been proposed.
HIL is a well-proven methodology from the automotive, avionics, and space
industries. The objective in HIL testing is to test the target system with respect to the
operational and safety functions and verify conformance to the functional and safety
requirements. This is accomplished by connecting the control system to a simulator
of the ship or offshore installation. The control system is then tested under realistic
operating conditions.
Dynamic Positioning (DP) and Power Management System (PMS) - Hardware
in the Loop (HIL) testing reduce quality costs of vessels and make the building,
commissioning and sea trial process predictable and efficient. The main advantage of
this approach is that software errors, configuration errors and faulty parameter
settings are detected during testing at an earlier project development stage. The
control system vendor can then correct errors and improve the solution
systematically, in advance of commissioning, sea trials and delivery of vessel.
In DP Control HIL testing the DP system will not be connected to the sensors
and thrusters of the ship. Instead the DP system is connected to the CyberSea DP-
HIL Simulator. The simulator receives command signals from the DP system and
calculates the motions of the vessel. The simulator returns simulated sensor signals
to the DP Control system.
In PMS-HIL testing, the PMS control system is connected to the real-time
CyberSea Simulator via a Fieldbus network, control network, or hardwired I/O
interface. At Factory Acceptance Test the CyberSea Simulator is used to simulate the
signals necessary for realistic closed loop operation of the PMS.
1
The simulator tools are configured and customized for each particular vessel
based on state-of-the-art mathematical models and the CyberSea Simulator
Technology. Interfacing solutions are developed together with the equipment
suppliers in order to ensure efficient and secure communication between the target
control system and the CyberSea Simulator.
This work describes the development of a tool/module as the communication
interface between the CyberSea Simulator and the control system of the vessel by
means of Profibus DP technology. The functions of the hardware/software system will
be tested by the simulator via the Profibus interfacing module, such that during
execution the hardware/software system will not experience any qualitative difference
from being integrated in the real system.
1.1: Objectives
The main goal of the project is to develop a solution for interfacing a test
simulator to various control systems using Profibus technology, assuring it is a
common tool for interfacing controllers from different vendors.
We implemented a Profibus communication interface to the CyberSea
Simulator and control system (Power Management System – PMS) of a drilling
vessel. On behalf of that we used the background and knowledge acquired during the
Control and Automation Engineering Course. The project covers different aspects of
control and automation: Profibus industrial protocol, communication between
networks over UDP/IP, control system, data transferring and simulation.
The programmed module for the Profibus communication interface is intended
to be a common/standardized tool for interfacing test simulators to control systems
from different vendors. So that it will save time on programming the interfacing S-
function and also it will facilitate the assembly of the simulator on the real system.
As the control system being simulated have 4 PLC controllers to be connected
to the CyberSea Simulator, a computer networking via a switch will be implemented.
For the communication between these networks the protocol mechanisms over
UDP/IP are going to be used. A simplified overview of the project is on Figure 1.
2
Figure 1: Simplified overview of the project
1.2: Structure
The work is organized in 7 chapters comprehending theoretical background,
the case of study, the implementation phase and bibliography.
Chapter 2 composes the theoretical background exploiting the knowledge
base involved during the work. It introduces concepts of Profibus technology and
computer networking, and also contextualizes the power management system in
marine vessels.
Chapter 3 will explain the simulation procedure for testing of vessels control
system, which includes the Hardware in the Loop testing and the CyberSea Simulator
developed by Marine Cybernetics.
Chapter 4 consists of a detailed description of the studied case, including the
drilling vessel, its control systems and the plant simulator requirements for the
project.
3
Chapter 5 brings the implementation aspects of the Profibus DP
communication interface and the network data exchange via UDP; and it describes
the results for the testing and validation phase.
Chapter 6 briefly explains the programming of the S-Functions blocks, also
stating the main callbacks methods of an S-function.
Chapter 7 ends the work with the conclusions and future work followed by the
bibliography list.
The specification requirements for the CyberSea Profibus DP/PA slave
module and for the UDP communication modules are stated in the appendixes.
1.3: About the Company Marine Cybernetics AS
Marine Cybernetics (MC) was founded by 4 professors from NTNU
(Norwegian University of Science and Technology, Trondheim - Norway), an Attorney
at Law and a Business Consultant in December of 2002. Today it has a structure
divided into the following sectors: Administration, Quality Management Systems
Manager, Research & Development, Operations, Marketing and Sales.
Marine Cybernetics improves safety and profitability for the customers through
independent testing of mission-critical control systems on ships and offshore
installations. This is done using Hardware-In-the-Loop (HIL) testing based on the
patented CyberSea Simulator Technology.
The company provides:
• use of a vessel specific CyberSea Simulator connected to the target
control system, for use at factory test and onboard testing;
• a vessel specific comprehensive test program based on the equipment,
functionality and operational philosophy of the vessel. The acceptance
criteria and test scenarios are based on class and the International
Maritime Organization (IMO) requirements, client requirements,
reported incidents, and other international standards and guidelines;
4
• verification of operational procedures and an opportunity for training of
personnel during onboard HIL testing;
• documentation and quality assurance in compliance with DNV's (Det
Norske Veritas) standard for certification of HIL testing.
In spring of 2007 about 20 vessels have been subjected to HIL testing by
Marine Cybernetics, including dynamic positioning or power management systems on
drilling vessels, diving support vessels, well intervention vessels, shuttle tankers, and
other offshore vessels.
Marine Cybernetics offers consulting services for Concept and Design Review
of Control Systems including dynamic positioning systems, vessel automatic system,
thruster and propulsion systems, crane systems, drilling systems and navigation,
sensor and nautical systems.
Marine Cybernetics customers comprise: oil companies, contractors, ship
operators , vendors, class societies, yards, authorities, navy and consultancies.
5
Chapter 2: Background
This chapter exposes the core technologies applied for the project‘s
implementation. It will elucidate main concepts about Profibus and computer network,
as an attempt to achieve a better understanding of the project’s background.
It will also detail the foundation of the control system of a typical vessel, in
order to give overview about the electrical propulsion and power management
systems.
2.1: Profibus
Profibus was created in 1989 by a consortium of companies and institutions,
and it has become the world’s most popular fieldbus in discrete manufacturing and
process control. It is ideal for supporting modern automation systems. With over 14
million installed devices, it is a significant driving force for the world’s production
plants. Profibus offers a fully integrated solution for discrete and process applications,
a major benefit in the process industries where upstream, mainstream and
downstream processes have to work together.
Profibus is an open, digital communication system with a wide range of
applications, particularly in the fields of factory and process automation. Profibus is
suitable for both fast, time-critical applications and complex communications tasks.
The type of industry using Profibus ranges from critical petrochemical plants to
high volume robotic manufacturing plants, right across the spectrum to food and
beverage industries, etc.
Profibus allows communication between devices of different manufacturers
without any special interface adjustment. It can be used for both high-speed time
critical applications and complex communication tasks [1] [2].
6
2.1.1: Standard
Profibus has been standardized in IEC 61158 with other Fieldbus systems.
IEC 61158 bears the title “Digital data communication for measurement and control –
Fieldbus for use in industrial control systems” and it is split up into 6 parts numbered
61158-1 to 61158-6. Table 1 provides an overview of the individual parts of IEC
61158.
IEC 61158
Document
IEC Document Content OSI
Layer
IEC 61158-1 Introduction
IEC 61158-2 Physical Layer Specification and Service Definition 1
IEC 61158-3 Data Link Service Definition 2
IEC 61158-4 Data Link Protocol Specification 2
IEC 61158-5 Application Layer Service Definition 7
IEC 61158-6 Application Layer Protocol Specification 7
Table 1: Structure of IEC 61158
The ten most widespread fieldbus systems in the world are to be found in IEC
61158 with the definition of the “Fieldbus protocol types” referred to as Types 1 to 10.
Table 2 shows the classification of these ten types according to Fieldbus systems.
Profibus is defined as Type 3.
Profibus has two versions in IEC 61158 regarding different requirements of
industry:
Profibus DP (Decentralized Periphery) is used for fast data exchange in
production engineering and facility automation. It uses RS485
transmission technology.
Profibus PA (Process Automation) fulfills the requirements of process
industry and offers applications for intrinsically safe and non-intrinsically
safe sectors, as well as the option of supplying power to field devices
via the bus. Typically with MBP/IS transmission technology.
7
Historically FMS was the first Profibus version; however it is no longer part of
the current version of IEC 61158.
Protocol Types (families) specified in IEC 61158
Type 1 Foundation Fieldbus (FF)
Type 2 Control Net
Type 3 Profibus
Type 4 P-Net
Type 5 FF High Speed Ethernet
Type 6 SwiftNet
Type 7 World FIP
Type 8 Interbus
Type 9 Foundation Fieldbus (FF), FMS
Type 10 Profinet
Table 2: The fieldbuses in IEC 61158
2.1.2: Profibus in the ISO/OSI Model
To be able to assess a communication system and compare it with others, it
has proved helpful to classify it relative to a standardized reference model. The
international reference model used to illustrate communication for open systems is
the ISO/OSI model introduced in 1978. The ISO/OSI model defines the elements,
structures and tasks required for communication and divides the sequence of any
communication into 7 layers, which are listed in the Table 3.
The Profibus layers used are 1, 2 and 7. For the two protocol types DP and
FMS layers 1 and 2 are identical, both transmission physics and the telegram format
are identical. The FMS part is defined in the user layers (Layer 7). For reasons of
efficiency, with Profibus DP layer 7 is blank. DP is thus to be regarded as a
standardized application of layer 2 [13].
8
Layer Number Layer Name Function
Layer 7 Application Layer Interface to application program with application-
oriented commands (read, write)
Layer 6 Presentation
Layer
Representation (coding) of data for analysis and
interpretation in the next layer
Layer 5 Session Layer Establishing and clearing temporary station
connections, synchronization of communication
processes
Layer 4 Transport Layer Controlling data transmission for layer 5
(transport errors, break down into packets)
Layer 3 Network Layer Establishing and clearing connections, avoiding
network congestion
Layer 2 Data Link Layer Description of bus access protocol (Medium
Access Control, MAC) including data security
Layer 1 Physical Layer Definition of the medium (hardware), coding and
speed of the data transmission
Table 3: The OSI reference model
2.1.3: Application Areas of Profibus
As far as the requirements for a communication system are concerned,
important aspects are the volume of data, transmission time and transmission
frequency when integrating into the respective level in the hierarchy. Figure 2 shows
the main application of Profibus in the cell and field area. Table 4 shows the major
criteria that are helpful when classifying a communication system.
In industrial communication the demand is for future oriented automation
concepts which can communicate both horizontally and vertically via a number of
hierarchical levels. Graduated and harmonized industrial communication systems like
Profibus with its connection of AS interface downward and to Ethernet upward
provide ideal conditions for transparent networking throughout all areas of the
production process.
9
Figure 2: Application areas of Profibus within the production pyramid
Level Data Volume Transmission time Transmission frequency
Management Mbytes Hours / minutes Day / shift
Cell Kbytes Seconds Hours / minutes
Field Bytes 10m s – 100m s 10m s – 100m s
Actuator/sensor Bit 100μ s – 100m s milliseconds
Table 4: Requirements for communication systems
At the actuator/sensor level the signals from the binary sensors and actuators
are transmitted via a sensor/actuator bus. The data and energy are transferred via a
common medium.
At the field level the decentralized peripheral devices like I/O modules,
measuring transducers, drives, analytical devices, valves or operator terminals
communicate with the automation systems via a powerful real-time communication
system. The transmission of process data is cyclic. If necessary alarms, parameters
and status messages can be transmitted acyclically.
Automation devices like PLC and IPC (Inter-Process Communication)
communicate with one another at cell level. The flow of information requires large
packets and a large number of powerful communication functions.
10
Fieldbuses are industrial communication systems that can use various media
such as copper cable, fiber-optic cable or radio. With bit-serial transmission they are
connected to a centralized control or coordination system in order to link up widely
distributed field devises.
Profibus DP regards its main application as being in the field area with
required response times in the region of 10 to a 100 milliseconds. The areas of
application for fast digital data exchange, like Profibus, in the field area have
expanded considerably due to the possibilities for intelligent data processing. On
account of the large bandwidth of the transfer rate (9.6Kbits/s to 12Mbits/s) and the
specified data volume per telegram of 244 bytes maximum.
2.1.4: Transmission Technologies
There is a whole range of transmission technologies available for Profibus:
• RS485: it is the most commonly used transmission technology. It uses
a shielded twisted pair cable and enables transmission rates up to
12Mbit/s.
• RS485-IS: it is a newly specified version of RS485. It has a 4-wire
medium in protection type Eex-i for use in potentially explosive areas.
The specified levels of voltage and current refer to the safety-relevant
maximum values that must not be exceeded in either individual devices
or during interconnection in the system.
• MBP (Manchester Coded, Bus Powered): it is available for applications
in process automation with a demand for bus powering and intrinsic
safety of devices.
• Fiber Optic: it is suitable for use in areas with high electromagnetic
interference or where greater network distances are required.
2.1.5: Communication Protocol DP
The main function of the Profibus-DP is the cyclical transmission of process
data from the control system to the peripherals and in the reverse direction. The
access is made by the master-slave principle. A master controls the assigned slave
11
devices on the bus in polling operation. Data exchange is initiated by a polling
message and terminated by an acknowledgment message from the slave addressed.
Each slave therefore only becomes active when required by the master.
Simultaneous bus access is thus avoided.
The hybrid access method of Profibus permits combined operation of several
bus masters and even mixed operation of Profibus-DP and Profibus-FMS within a
single bus section. This however depends on the correct configuration of the bus
system and unequivocal assignment of the slave devices to the masters.
Geared towards the special demands of the various areas of application, the
basic DP functions have been expanded step-by-step with special functions, so that
DP is now available in three versions: DP-V0, DP-V1 and DP-V2. The key contents
of the three versions are as follows:
• DP-V0: provides the basic functionality of DP, including cyclic data
exchange as well as station diagnosis, module diagnosis and channel-
specific diagnosis.
• DP-V1: contains enhancements geared towards process automation,
in particular acyclic data communication for parameter assignment,
operation, visualization and alarm handling of intelligent field devices,
parallel to cyclic user data communication. This permits online access
to stations using engineering tools. It also defines status alarm, update
and a manufacture-specific alarm.
• DP-V2: contains further enhancements and it is geared primarily
towards the demands of drive technology. Due to additional
functionalities, such as isochronous slave mode and slave-to-slave
communication. It can also be implemented as a drive bus for
controlling fast movement sequences in drive axes.
As the project will deal with Profibus DP-V0, a special attention will be given to
this version.
12
2.1.5.1: Basic Functions of DP-V0
The central controller (master) reads input information from the slaves
cyclically and writes output information to the slaves cyclically.
The bus cycle time should be shorter than the program cycle time of the
central automation system, which is approximately 10ms for many applications.
However a faster data throughput alone is not enough for successful implementation
of a bus system. Simple handling, good diagnosis capabilities and interference-proof
transmission technology are also key factors. DP provides and optimum combination
of these characteristics.
Each DP system is made up of 3 different device types.
• DP Master Class 1 (DPM1): this is a central controller that cyclically
exchanges information with the distributed stations (slaves) at a
specified message cycle. Typical DPM1 devices are programmable
logic controllers (PLC) or PCs. A DPM1 has active bus access with
which it can read measurement data (inputs) of the field devices and
write the setpoint values (outputs) of the actuators at fixed times. This
continuously repeating cycle is the basis of the automation function.
• DP Master Class 2 (DPM2): devices of this type are engineering,
configuration or operating devices. They are implemented during
commissioning, and they are used for maintenance and diagnosis in
order to configure connected devices, evaluate measured values and
parameters and request the device status. A DPM2 does not have to be
permanently connected to the bus system. It also has active bus
access.
• Slaves: a slave is a peripheral (I/O devices, drives, valves, transducers,
analysis devices), which reads process information and/or uses output
information to intervene in the process. There are also devices that
solely process input information or output information. As far as
communication is concerned, slaves are passive devices, they only
respond to direct queries. This behavior is simple and cost-effective to
implement.
13
In the case of mono-master systems, only one master is active on the bus
during operation of the bus system, as it can be seen in Figure 3. The PLC is the
central control component. The slaves are coupled to the PLC over the transmission
medium. This system configuration enables the shortest bus cycle times.
Figure 3: Profibus DP mono-master system
In multi-master operation several masters are connected to one bus. They
represent either independent subsystems, comprising one DPM1 and its assigned
slaves, or additional configuration and diagnosis devices. The input and output
images of the slaves can be read by all DP masters, while only one DP master can
write-access the outputs.
An overview of the DP-V0 is in Table 5.
Bus Access Token passing procedure between master and data passing
between masters and slaves
Mono-master or multi-master system option
Master and slave devices, maximum 126 station on one bus
Communication Peer-to-peer (user data communication) or multicast (control
commands)
Operating
States
Operate: cyclic transmission of input and output data
Clear: inputs are read, outputs remain in fail-safe state
Stop: diagnosis and parameter assignment, no user data
transmission
14
Sychronization Control commands enable the synchronization of inputs and
outputs
Sync mode: outputs are synchronized
Freeze mode: inputs are synchronized
Functionality Cyclic user data transfer between DP master and slave(s)
Dynamic activation/deactivation of individual slaves; checking
of slave configuration
Powerful diagnosis functions, 3 levels of diagnostic messages
Synchronization of inputs and/or outputs
Optional address assignment for slaves over the bus
Maximum 244 bytes of input/output data per slave
Protective
functions
Watchdog control of DP slaves detects failure of assigned
master
Access protection for outputs of slaves
Monitoring of user data communication with adjustable
monitoring timer in master
Devices types DP master class 1: PLCs, PCs
DP master class 2: engineering or diagnosis tools
DP slave: devices with binary or analog inputs/outputs, drives,
valves
Table 5: Overview of the DP-V0
2.1.6: Addressing with Slot and Index
When addressing data, Profibus assumes that the physical structure of the
slaves is modular or that it can be structured internally in logical functional units, so-
called modules. This model is also used in the basic DP functions for cyclic data
communication, where each module has a constant number of input/output bytes that
15
are transmitted in a fixed position in the user data telegram. The addressing
procedure is based on identifiers, which characterize a module type as input, output
or a combination of both. All identifiers combined produce the configuration of a
slave, which is also checked by the DPM1 when the system stars up. Figure 4 shows
the addressing with slot and index.
The acyclic data communication is also based on this model. All data blocks
enabled for read/write access are also regarded as assigned to the modules and they
can be addressed using slot number and index. The slot number addresses the
module, and the index addresses the data blocks assigned to a module. Each data
block can be up to 244 bytes. In the case of modular devices, the slot number is
assigned to the modules. The modules begin at 1 and are numbered in ascending
contiguous sequence.
Figure 4: Addressing with slot and index
Through the length specification in the read/write request it is also possible to
read/write parts of a data block. When access to the data block is successful, the
slave sends a positive read/write response or it may otherwise be able to classify the
problem by means of its negative response.
16
2.1.7: Commissioning
Before a PROFIBUS-DP system can be put into operation, all the connected
stations including the master system must be given unequivocal bus addresses.
The physical system settings are made using the master parameter set. This
contains the master bus address and, for example, the baud rate, the timeout
settings and the number of transmission retries. Together with the master parameter
set, a slave data set has to be stored for each slave to be activated. Each data set
contains the parameterization and configuration data of the slave and the address
vectors for the logical storage of the I/O data.
When the parameter sets are available, the master system begins to start up
the slaves in succession on instruction by the user or automatically. The first
diagnostic cycles indicate which slaves are present on the bus. Only those slaves
which have sent a correct feedback message in the diagnostic cycle are then
parameterized with the relevant data stored in the master in subsequent
parameterization cycles. When this has been performed correctly, configuration
cycles follow with the comparison of the specified configuration data in the master
and the actual configuration data in the slaves. After the last diagnostic cycle, each
slave that has not detected an error in the comparison is ready for operation. Each of
these slaves are then automatically included in the user data transfer by the master.
For diagnostic, the master maintains a diagnostic buffer for each slave, which
can be read by the user. For simplified diagnostic, a group diagnostic field is
maintained at the same time, showing bit by bit whether a slave has diagnostic data
ready or not [14].
2.1.8: Profibus GSD File
The GSD file is a readable ASCII text file and it contains both general and
device/specific specifications for communication. Each of the entries describes a
feature that is supported by a device. To define the technical details of a field device
in a standardized manner a large number of keywords were defined, each of which
defines a certain property of the field device unambiguously. By means of keywords,
a configuration tool reads from the GSD file the device identification, the adjustable
parameters, the corresponding data type and the permitted limit values for the
17
configuration of the device. Some of the keywords are mandatory, for example
Vendor_Name. A GSD replaces the previously conventional manual and supports
automatic checks for input error and data consistency, even during the configuration
phase.
2.2: Computer Networking
Computer networking is the communication between computer systems or
devices. Communicating computer systems constitute a computer network which
generally involve at least two devices capable of being networked with at least one
usually being a computer. The devices can be separated by a few meters (e.g. via
Bluetooth) or nearly unlimited distances (e.g. via internet).
Examples of networks are the Internet, or a local area network (LAN) with two
computers connected with standard networking cables connecting to a network
interface card in each computer.
2.2.1: TCP/IP Model
The TCP/IP model or Internet reference model is a layered abstract
description for communications and computer network protocol design. It was created
in the 1970s by DARPA for use in developing the Internet’s protocol, and the
structure of the Internet is still closely reflected by the TCP/IP model.
Today's TCP/IP networking represents a synthesis of two developments that
began in the 1970s, namely LANs (Local Area Networks) and the Internet, both of
which have revolutionized computing.
TCP/IP can be viewed as a set of layers, each layer solves a set of problems
involving the transmission of data, and provides a well-defined service to the upper
layer protocols based on using services from some lower layers. Upper layers are
logically closer to the user and deal with more abstract data, relying on lower layer
protocols to translate data into forms that can eventually be physically transmitted.
The original TCP/IP reference model consists of 4 layers, but has evolved into a 5-
layer model.
18
The User Datagram Protocol (UDP) is one of the core protocols of the TCP/IP
model. The protocol mechanisms over UDP/IP for communication between networks
are going to be used in this project, so a closer attention will be given to UDP.
2.2.2: User Datagram Protocol (UDP)
UDP (User Datagram Protocol) guarantees the error-free, sequential,
complete transmission of data from sender to receiver. However, in contrast to TCP,
UDP is connectionless, that is, each data packet is treated as an individual
transmission and there is no transport confirmation. Omission of timeout monitoring,
and clear down of connections make UDP more suitable for time-critical applications
than TCP.
The User Datagram Protocol offers only a minimal transport service, non-
guaranteed datagram delivery, and it gives applications direct access to the
datagram service of the IP layer. UDP is used by applications that do not require the
level of service of TCP or that wish to use communications services (e.g., multicast or
broadcast delivery) not available from TCP.
In general, UDP implements a fairly "lightweight" layer above the Internet
Protocol, it is stated on the Transport Layer of the TCP/IP model. UDP's main
purpose is to abstract network traffic in the form of datagrams. A datagram comprises
one single "unit" of binary data; the first 8 bytes of a datagram contain the header
information and the remaining bytes contain the data itself.
The UDP header consists of 4 fields of two bytes each. The fields are:
• source port number;
• destination port number;
• datagram size;
• checksum.
UDP port numbers allow different applications to maintain their own channels
for data; both UDP and TCP use this mechanism to support multiple applications
sending and receiving data concurrently. The sending application (that could be a
client or a server) sends UDP datagrams through the source port, and the recipient of
the packet accepts this datagram through the destination port. Some applications use
19
static port numbers that are reserved for or registered to the application. Other
applications use dynamic (unregistered) port numbers. Because the UDP port
headers are two bytes long, valid port numbers range from 0 to 65535; by
convention, values above 49151 represent dynamic ports.
The UDP datagram size is a simple count of the number of bytes contained in
the header and data sections. Because the header length is a fixed size, this field
essentially refers to the length of the variable-sized data portion. The maximum size
of a datagram varies depending on the operating environment. With a two-byte size
field, the theoretical maximum size is 65535 bytes. However, some implementations
of UDP restrict the datagram to a smaller number, sometimes as low as 8192 bytes.
UDP checksums work as a safety feature. The checksum value represents an
encoding of the datagram that is calculated first by the sender and later by the
receiver. Should an individual datagram be tampered with (due to a hacker) or get
corrupted during transmission (due to line noise, for example), the calculations of the
sender and receiver will not match, and the UDP protocol will detect this error. The
algorithm is not fool-proof, but it is effective in many cases. In UDP, check summing
is optional (turning it off gives a little extra performance from the system) as opposed
to TCP where checksums are mandatory.
2.3: Power Management in Marine Vessels
Power system comprehend the systems and equipments necessary to supply
electric power to all the consumer units in the control system. The control contributes
to the satisfactory operation of the power system by maintaining system voltages,
frequency and other system variables within their acceptable limits. They also have a
profound effect on the dynamic performance of the power system and on its ability to
cope with disturbances.
2.3.1: Control System
Control is to monitor and/or command the essential states of a physical
process autonomously using technological components such as sensors, actuators,
and computer equipment. Pure monitoring (using sensors) or pure commanding
20
(using actuators) yields open-loop systems, while combining equipment for both
monitoring and command through computer control algorithms yields a closed-loop
feedback system that satisfies an overall control objective. The most common control
objectives are regulation, which control the process output variables to fixed
references, and tracking, which make the output variables track time-varying
references.
The main subsystems of a control system are:
• power system;
• actuator system;
• sensor system;
• control computer system.
In a DP System according to [9], the actuator system is called the thruster
system, the control computer system is called the DP computer system and the
sensor system consists of position reference systems and other sensors such as
gyros, and wind sensors.
A marine vessel consists usually of many control systems, e.g. electric power
generation and distribution, propulsion systems, ballast systems, cranes, drilling,
dynamic positioning, nautical systems, which form the automation system.
The power system and the thruster system are integrated subsystems in a DP
system, but have functions beyond DP; the power system must deliver power to all
other consumers and the thruster system must also respond to commands from e.g.
nautical systems.
2.3.2: Dynamic positioning
Dynamic positioning (DP) is a system that automatically maintain a ship’s
position and heading by using its own propellers and thrusters. This allows
operations at sea where mooring or anchoring is not feasible due to deep water,
congestion on the sea bottom (pipelines, templates) or other problems.
21
Dynamic positioning may either be absolute in that the position is locked to a
fixed point over the bottom, or relative to a moving object like another ship or an
underwater vehicle.
A Dynamic Positioning system consists of a set of equipment/functions not
only the DP control system itself. The complete DP system is composed by:
1. Power system:
• generator and prime movers;
• main switchboard;
• bus-tie breaker;
• distribution system;
• power management.
2. Thrusters Control:
• arrangement of thrusters;
• auto control;
• manual control;
• single levers for each thruster.
3. Sensors:
• position reference systems;
• external sensors: wind, VRS, Gyro compass, others.
4. UPS – Uninterrupted Power Supply
5. Alternate
2.3.3: Electric Propulsion Systems
Electric propulsion systems for ships have become the preferred solution for
several kinds of vessels over the last years. Such systems with electrical propulsion
motors, variable speed thruster drives, and a common power station with several
diesel-generators or gas turbines, have proven to be beneficial in several ways. Fuel
saving, lower maintenance costs, improved maneuverability, higher reliability,
reduced noise and vibration are some to be mentioned. These benefits weight up the
extra initial costs and increased number of components, much because an electrical
system is very flexible with respect to operation, control and location on board. The
electrical equipment also utilizes a high efficiency over a large range of operation [6].
22
The basic idea with such systems is to replace the main diesel propulsion
engines with electric motors, and split the power production into several smaller
diesel-generators. Electrical motors can be designed with a very high efficiency
throughout the whole range of operation with respect to both speed and power
outputs, in contrast to the diesel engine which has a clear peak in efficiency around
its nominal working point. A ship that varies its velocity will be able to operate with a
high efficiency for the whole range of operation by selecting the optimal number of
diesel generators to supply the desired power demand.
Diesel-generators with synchronous machines (typically 3-8 units) are usually
used for the power production. The generators supply the main switchboard with
active (P) and reactive (Q) power. This switchboard is divided into two or more
sections to ensure redundancy. The voltage level will vary with installed power,
typically 11kV for installed power above 20MW. High voltage is necessary to keep
short circuit currents and load currents low.
2.3.4: Power Management Systems (PMS)
A power management system controls and monitors the operation of the
diesel electric propulsion system. It selects how many and which generators to run,
depending on the load demand from thrusters, pumps and other loads or from
manual settings. Normal PMS functions are usually load dependent start and stop of
generators, heavy consumer handling and load shedding. For load dependent start
and stop of generators the PMS systems sends out a start signal to the next
generator in the start-sequence when the load has increased above a predefined
load limit for a certain time. This generator is then started, synchronized and
connected to the switchboard. When the load has decreased below a predefined stop
limit the PMS sends a stop signal to the last generator in sequence. Heavy consumer
handling is to check for available power when starting large loads. If the available
power is sufficient for this load a start signal is sent, otherwise a new generator is
started before the signal is sent [8].
A typical PMS configuration can be seen in Figure 5.
23
Figure 5: PMS configuration
A properly designed and operated power system should meet the following
fundamental requirements [7]:
1. The system must be able to meet the continually changing load demand
for active and reactive power. Unlike other types of energy, electricity cannot
be conveniently stored in sufficient quantities. Therefore, adequate spinning
reserve of active and reactive power should be maintained and appropriately
controlled at all times.
2. The system should supply energy at minimum cost and with minimum
ecological impact.
3. The quality of power supply must meet certain minimum standards with
regard to the following factors:
a. constancy of frequency;
b. constancy of voltage;
c. level of reliability.
The control objectives are dependent on the operating state of the power
system. Under normal conditions, the control objective is to operate as efficiently as
possible with voltages and frequency close to nominal values. When an abnormal
condition develops, new objectives must be met to restore the system to normal
operation.
24
Major system failures are rarely the result of a single catastrophic disturbance
causing collapse of an apparently secure system. Such failures are usually brought
about by a combination of circumstances that stress the network beyond its
capability. Severe natural disturbances (such as a tornado, severe storm or freezing
rain) equipment malfunction, human error and inadequate design can eventually lead
to its breakdown. This may result in cascading outages that must be contained within
a small part of the system in order to prevent a major blackout.
25
Chapter 3: Simulation for Vessel Testing
Simulation plays an important part in the design, maintenance and upgrading
of control systems. The dynamic systems to be controlled are usually described by
differential equations or transfer functions, and simulation is used to check the
qualitative behaviors of the system for typical parameter values and for expected
modes of operation. When a controller is designed for a system it is an usual practice
to test the controller in simulations before implementing it. This allows for rapid
changes and correction of errors before the system is designed. Also it is important to
test the procedures for handling of discrete events and errors. For systems where a
controller has already been developed, quantitative aspects of simulation are
important for the fine tuning of controller parameters and the redesign of the systems
to be controlled.
For ship control systems there are large costs involved in commissioning of
control systems, which involves installation and calibration. Moreover, a typical
situation is that there is very little time available for the control engineer to
commission the controllers before the ship is to be set into commercial operation.
The time needed for commissioning can be reduced significantly using simulation,
and this may be a decisive factor in order to make control systems commercially
attractive for the marine industry.
A plant or component can be implemented in SW based on decision rules and
logical switching, or it can be implemented based on accurate equations given by
physical first principles such as Newtonian physics. An actuator may be modeled, for
instance, by accurate dynamic equations representing its true behavior, or by some
simplifying characteristic curves that approximate its dynamic behavior.
The most realistic behavior of the system is obtained by a high and accurate
level of modeling. However, this will also require more know-how and a larger
amount of parameters to be collected and configured into the simulator. In practice,
the implementation of the different units will be a trade-off based on available
configuration data and the know-how among the HIL designers.
26
This chapter will take a closer look in HIL testing of modern ships, it will
explain how HIL simulator operates, which are the interfaces to a control computer
system, it will give some definitions about fault, failure and failure mode. And finally it
will detail Marine Cybernetics’ CyberSea Simulator functionalities.
3.1: HIL Testing in Modern Ships
Hardware-in-the-Loop (HIL) testing is proposed as a new methodology for
verification and certification of marine control systems. In HIL testing the control
system is connected to a real-time simulator instead of the ship. This allows for
extensive testing of the control system before commissioning and sea-trials.
Moreover, the use of HIL-testing makes it possible to test the control system under
test conditions that may compromise the safety of the ship and crew, like high sea-
states in combination with possible black-out situations in the power system [5].
Simulation-based testing has been adopted as an important tool for verification
and validation of control systems in the automotive and aerospace industries, and to
some extent in the maritime industry. The role of simulation varies in the different
stages of the control system development. To discuss this further it is convenient to
describe control systems development in terms of the commonly used V-cycle
(Figure 6).
Figure 6: Control system development according to the V-cycle.
27
The left side of the V is related to the design stages, whereas the right side of
the V is related to verification and validation.
In the automotive industry, the car manufacturer will be responsible for control
systems design, and at the same time for verification and validation. The maritime
industry has a different structure where the class societies play a central role in
verification and validation. Moreover, for DP vessels there are independent
companies that perform FMEA (Failure Mode and Effects Analysis) testing on control
systems. As control systems are becoming more complex, the class societies will
have to adopt new methods for testing, and HIL-testing will be an important tool in
this connection.
The HIL simulator used by the class societies for verification at the Factory
Acceptance Test (FAT), and for validation at sea trials, should be developed
independently from the control system vendor, and it should not have been used in
the design process and in the internal testing of the vendor. The motivation for this is
that the final verification and validation by the class society should pose new
challenges to the control system.
Power systems pose a special challenge to modeling. This means that HIL
testing of DP vessels including the power system may be problematic. The reason for
this is that logical control due to switches, tripping, load shedding is closely integrated
in the power system dynamics, and HIL-testing of such systems may suffer from
inaccurate models. One solution to this problem is to perform HIL-testing where the
actual power system is in the loop, and to validate the power system with this type of
HIL-testing.
3.2: HIL Simulator
HIL simulator is a real-time simulator constructed by hardware and software
that is configured for the control system under consideration and interfaced to the
target system or component through appropriate I/O. During execution, the target
system or component will not experience any qualitative difference from being
integrated to the real system.
28
A HIL simulator operates in real time closed loop with the control computer
system and facilitates realistic and efficient testing of functionality, performance and
safety functions of the control system. The HIL simulator will usually have a
mathematical model of the specific plant and the environment modeled in software
together with peripheral equipment modeled to a varying degree in HW or SW.
3.3: Interface
The interfaces to a control computer system are the user interface, the signal
interface (I/O), and often there are special test interfaces. The user interface is
realized by the operator stations and its visual display units, monitoring and alarm
panels, keyboards, switches, and joysticks. Modern control systems often utilize
several computer panels with many view and dialogues.
The interface between the control computer system and the other subsystems
is the signal I/O interface. This is usually spread out in the installation by several
cabinets containing different equipment for processing the signals.
The signal I/O interface may also contain a specialized test interface for
connecting a HIL simulator to the control computer system. This allows for a
minimally invasive HW/SW testing of the control computer system since the real
signal cables in the integrated control system do not have to be disconnected for
testing to take place. This type of interface is the one used for the project, which will
interface the vessel system’s controller to the CyberSea Simulator.
3.4: Fault, Failure and Failure Mode
A defect in a component is called a fault. This results in a failure of that
component to perform at least one of its functions. This failure is manifested by a
failure mode, i.e., a functional deviation observed on the boundary of the component.
The component boundary can be output signals, physical actions or user
interface. A component in failure mode due to e.g. a software failure will in this
respect be identified by a deviation from the functional requirements of the
29
component. For instance, a fault of a thruster on a DP vessel can be the loss of one
of its propeller blades. One failure is then the inability of the thruster to produce the
specified thrust. The failure mode is that the thruster produces a reduced thrust force
as compared to its set-point.
Some typical failure modes within the different subsystems are in Table 6 [10].
Subsystem Failure Mode
Loss of electrical power at one or several switchboards.
Loss of UPS (Uninterrupted Power Supply) power.
Loss of power at one or several consumers.
Reduced quality of electrical power (wrong frequency, wrong
voltage, voltage surges).
Power System
Signal failure modes on PMS monitoring and command signals.
Loss of actuation effort at one or several actuation devices.
Erroneous actuation effort (scaling, offset, unsteady, drifting) at
one or several actuation devices.
Actuator System
Signal failure modes on actuator sensors.
Sensor System Signal failure modes on measurement signals.
Shutdown of controllers or processors.
Loss of power to OS, network devices.
User errors.
Signal interface (I/O) errors.
Network signal failure modes.
Erroneous setpoint sent to actuator system.
Control Computer
System
Erroneous control signal sent to power system.
Table 6: Typical failure modes within the different subsystems
If not handled properly, a component in failure mode may cause other
components or subsystems, and eventually the overall control system to fail its
30
function. Clearly, a large number of faults may potentially occur in a marine control
system. However, many faults result in the same failure in the system, and many
failures are manifested by the same failure mode. HIL testing should therefore test a
safety-critical control system with respect to a manageable set of failure modes.
3.5: CyberSea Simulator
The CyberSea Simulator environment provides a complete set of modules and
tools for building customized and configurable simulators for a wide range of maritime
and offshore applications. These include control system performance, capability and
failure testing using hardware-in-the-loop simulation, planning and verification of
marine operations, pre-contract specifications and integrated design.
The simulator platform is Simulink, which is a general purpose simulation
system based on MATLAB. A simulator is built by connecting blocks in a hierarchical
system representing a mathematical model. Each block may correspond to
elementary information processing operations or represent the mathematical model
of a complex dynamic system, such that each block may contain a hierarchical
system of sub-blocks.
The CyberSea Library provides configurable blocks that represent
mathematical models of:
• the equipment involved in marine operations: vessels, cranes,
including models of machinery, propulsion, thrusters, etc;
• the environment: waves, wind and current;
• information processing units such as control systems, navigation
systems, sensors and power management.
In addition to a library of model components, the CyberSea Library contains
information processing and interface blocks that allow the simulator to communicate
with a distributed control system through its hardware terminals (hardware-in-the-loop
simulation), with external hydrodynamics computation programs, and real-time
visualization programs.
31
The CyberSea Library thus consists of the following hierarchy of modules
which embrace the necessary functionalities of a vessel:
• Model Libraries containing Simulink blocks such as:
o marine vessels;
o marine environment;
o propulsion;
o sensor systems.
• Hydrodynamics interfaces
o interface to hydrodynamics computational software (coefficients);
o interface to a hydrodynamics coefficients database.
• Real-time communication blocksets
o RS232/422/485;
o TCP/IP and UDP;
o NMEA;
o FieldBus/CAN.
The CyberSea Library allows customized simulators to be generated for each
specific application simply by interconnecting and configuring existing blocks
available in a library. Each simulator constitutes a stand-alone executable program
that can run in real time. New or customized sets of blocks can be included in a
library, allowing models or parts of models to be reused.
The stand-alone executable simulator program does not require any MATLAB
or Simulink license. From a Simulator Manager program, the Simulator core can be
executed, the Simulator can be reconfigured, test sequences and scenarios can be
defined, and data resulting from the simulation can be monitored and stored for later
analysis.
The normal operation of a ship regarding the control system is shown in Figure
7. For the Factory Acceptance Test (FAT) the CyberSea Simulator is connected via
the normal controller I/O to any control computer system, the control system is
isolated, the vessel, environment and failure modes will be simulated, as shown in
32
Figure 8. For the validation at sea trials the CyberSea Simulator is connected to the
control computer system via network interface, as seen in Figure 9.
Figure 7: Normal Operation of a Vessel
Figure 8: Factory Acceptance Test
Figure 9: Dock and Sea trials
33
Chapter 4: Case Study
The project is developed for a drill ship unit. A drill ship is a maritime vessel
that has been fitted with drilling apparatus. It is most often used for exploratory drilling
of new oil or gas wells in deep water.
This chapter covers the control system used for this project. It explains how
the power management system is implemented on the drilling ship. It describes also
the requirements for the simulator, the interfacing to the control system, failure
modes and data logging.
4.1: The Drilling Vessel
There are two basic types of offshore drilling rigs: those that can be moved
from place to place, allowing multiple locations for drilling, and those rigs that are
permanently placed. Moveable rigs are often used for exploratory purposes because
they are much cheaper to use than permanent platforms. Once large deposits of
hydrocarbons have been found, a permanent platform is built to allow their extraction.
Drill Ship as the name suggests is a ship equipped for drilling operations.
Unlike the semi-submersible and jack up type rigs, it is maneuverable and moves
under its own power. They are not as stable as other mobile rigs but, equipped with
the latest technology, they cover large areas and are capable of drilling in very deep
water. Early ships maintained station by deploying anchors, but modern vessels use
DP (Dynamic Positioning).
The ship position is determined very accurately by means of satellite signals,
land based signals or from underwater sonar beacons. These outputs are linked to
the ships propulsion system and continual adjustments by computer are made so as
to maintain the ships position. These ships are used for many purposes including
drilling for oil and gas or taking sub seabed core samples [11].
Figure 10 shows an overview of a drilling vessel. Figure 11 exposes the main
vessel equipments, and it also shows how the CyberSea Simulator is connected
34
and/or interfaced to the control system. This interface is this project object of study
and it is based on Profibus DP technology.
Figure 10: Drilling vessel
Figure 11: Vessel’s sub-systems including interface to the CyberSea Simulator
35
4.2: PMS of the Drilling Unit
The most important task of the power management system is to supply
sufficient electrical energy during all of the operation modes of a rig. However, with
an increasing need of power on a plant the economical power generation is
considered almost as important as the freedom for interruption.
In case of malfunctions in the power supply system all necessary actions are
taken in order to supply the consumers with electrical energy without interruption, if
possible, and to avoid damage at the same time.
The PMS on the Drilling Unit is an integrated part of the control system IAS
(Integrated Automation System). For each engine room a single S7-400 PLC is
installed performing PMS functions and control functions (IAS). The single controller
consists of one rack, equipped with one CPU and several communication cards.
Communication cards installed interfaces simocode, and remote I/O.
For the Drilling Unit 8 diesel driven generators are installed, the generators are
grouped in 4 groups of 2 generators, each group making up a self-contained power
system.
For every DG-set, SIMATIC S7 standard components are used, which are
complemented by a generator protection unit/measuring transducer. This generator
protection unit/measuring transducer and SIMATIC S7 form an independent system
for each Diesel Generator (DG). In this way it is secured that only one generator set
is afflicted in case one system breaks down.
The power supply of the generator protection unit is designed redundantly, i.e.
every unit has an input from the superior UPS and an internal power supply fed by
the respective generator.
An extensive use of remote I/O and simocode via Profibus shall be used for
connecting equipment to the PMS controller. The Profibus DP protocol is used as
communication interface. Most of signals from switchboards, and the associated
auxiliary equipment, shall be connected to the PMS via remote I/O and simocode.
The communication between the Generator Protection relay (intelligent multifunction
protection relay) and the PMS will take place via Profibus DP [16]. The configuration
of the PMS for this project is shown in Figure 12.
36
Figure 12: PMS Diagram with Profibus communication interface
Controllers are integrated in the IAS system by common redundant Simatic
Ethernet.
4.3: Plant Simulator Requirements
The simulator should simulate the dynamics of the plant, and the behavior of
the PMS control system (the hardware is not included in the closed-loop). As a
minimum, the PMS computer, user interface, and communication links should be
included in the closed-loop for testing. All components should be simulated in the
time-domain in real time. The HIL simulator program must be embedded in a
computer external to the control system being tested.
The simulator should facilitate testability of the control computer system. This
means that the simulator should be capable of simulating the necessary range of
failures in equipment and signals according to a HIL test program. It should be an
integrated system simulator where the interactions between the different equipment
modules are correctly and accurately simulated.
An overview of a simplified configuration for a sea trial testing of the CyberSea
Simulator connected to the PMS computer system via a network interface, can be
seen in Figure 13.
37
Figure 13: PMS configuration
4.3.1: Interfacing to the Control Computer System
The HIL simulator should be interfaced to the power management control
computer via its signal input/output, through Profibus DP interface. This interface
should allow simulated sensor, actuator feedback, and power feedback signals to the
control computer system to be transmitted, and all actuator command signals sent by
the control computer system to be received by the simulator. It should be possible to
verify which signals are interfaced. The communication delay in the interface should
be less than 1/10 of the main sampling time in the control computer.
4.3.2: Failure modes
The simulator should be able to simulate the following general failures for all
signals:
1. Random signals: white noise, correlated noise (Markov process).
2. Deterministic signals: wild points, signal freeze, bias, drift, constant output
independent of input, scale-factor error, flags and status bits.
3. Profibus DP signal communication: erroneous rate of transmission,
checksum errors, and empty fields.
38
4. Power failures: simulated failures in a UPS or low-voltage power system
module should cause a simulated loss of power of the units connected to
the module.
4.3.3: Monitoring, Data Logging and Test Scenario Scheduling
The simulator shall have capabilities for data login and real-time presentation
of simulation results, such as trend plots and statistical properties. Deterministic
(repeatable) simulations of pre-determined simulation scenarios should be possible.
The purpose and implementation of each test should be presented in a clear manner
in the simulator user interface such that test completion and test result can be
witnessed and verified in a transparent manner. The simulator should contain internal
quality monitoring in order to automatically detect and report when internal sub-
models operate outside their validity range.
39
Chapter 5: Implementation and Validation
In this section it will be explained the implementation of the Profibus DP
communication interface module between the CyberSea Simulator and the PMS
control system of the drilling unit; and also the network data exchange using UDP/IP
between the Simulator and the remote I/O computers.
It will be described the testing and results of the CyberSea Simulator Profibus
DP/PA Slave module according to the requirements in Appendix A and Appendix B.
5.1: Overview of the Project
The project consists of the development of a Profibus DP communication
interface module between the CyberSea Simulator and the PMS control system of
the drilling unit (via a remote I/O computer), in order to exchange signals.
The Profibus DP communication interface is programmed in S-function
(section 5.3.1:), which is a computer language description of a Simulink block and it
is written in C++ programming language.
The PMS of the drilling vessel consists of four S7-400 PLCs, each one with
three masters. One Profibus DP bus system consists of a master connected to a
slave device composed by a switchboard with 8 intelligent multifunction protection
relays; the 2 other Profibus DP bus systems include a master that is connected to a
remote I/O slave device. Each relay has approximately 25 signals, and one remote
I/O has about 100 signals. Therefore, the project will deal with 400 signals for each
PLC controller.
Each PLC will be connected via Profibus DP to a personal computer (remote
I/O computer), which will emulate the slave devices (remote I/O and switchboard);
the slaves will be removed from the real system so the simulation can take place.
These remote I/O computers will emulate the slaves using Siemens SymbaSys PCI
module, which can simulate 125 Profibus DP/PA slaves per channel (section 5.3.2:).
40
The computer network will be set with 4 remote I/O computers connected
through a switch to the CyberSea Simulator in order to the exchange data via UDP
messages.
The CyberSea Simulator is composed by the Simulator computer and
Simulation Manager. The communication between these 2 parts is by TCP/IP and
RPC on Ethernet.
The Figure 14 shows how the project is implemented.
Figure 14: Project Implementation
5.2: Simulation Environment
In this project Matlab and Simulink provide an efficient and flexible platform for
real-time simulator development. This simulation environment includes C compilers
and tools like Real-Time Workshop that allow for real-time simulation.
Contrary to some claims we find that Simulink is also well suited for modeling
that is based on network formulations with component-based models that are
connected with port variables [6]. On background of this we have decided to
standardize all our simulator development on the Matlab/Simulink environment.
41
5.3: Profibus DP Communication Interface
The remote I/O computer, as seen in Figure 14, is composed by many
modules as shown in Figure 15. Each of these modules will be explained below.
Figure 15: Modules of the Profibus DP slave block
The pbusSlave block handles Profibus DP/PA communication between the
CyberSea Simulator and any unit with Profibus DP/PA slave interface. The signals
are converted from Simulink format to Profibus format, and vice versa. The block also
handles scaling and bias for the signals.
The module consists of 1 block:
• pbusSlave: a Simulink S-function block that sends and receives data
to/from Profibus DP/PA compatible unit (SimbaSys PCI board). The
Appendix A describes the Requirements Specification for CyberSea
Profibus DP/PA Slave module.
42
The block uses 2 common libraries:
• “SimbaProLib.dll”: it has 2 main functionalities, it reads an XML
formatted configuration file (using the external C++ library Xerces) and
it has all the SimbaPro functionalities for initializing the program, read
and write from/to slaves and finalize the SimbaPro program. (For more
details see Section 6.6:.)
• “CyberSeaMsgDLL.dll”: it displays debug and error information.
The simulation of the Profibus components is carried out by the SimbaSys-PCI
module connected to the Profibus Master. The project is created in the SimbaPro
software, which can simulate up to 125 slaves. One project can handle up to 32
simulation lines.
The configuration of the simulated Profibus network can be done by using the
integrated configuration tool (manually) or by import of the data files from PCS7
configuration.
An input file consisting of a specific data structure in XML format must specify
the configuration data for the signal (section 5.3.3.1:). The overall configuration of the
signals can be reconfigured between two simulation runs. The preprocessor (Matlab
m-file) is used to convert an Excel data structure containing some configuration
parameters into the data configuration input file ins an XML format.
The module communicates with a Siemens PLC controller using UDP
messages. A single port is used for transmitting data from the simulator and a single
port is used for transmitting data from the remote I/O computer.
5.3.1: S-function
An S-function is a computer language description of a Simulink block. S-
functions can be written in Matlab, C, C++, Ada or Fortran. C, C++, Ada and
FORTRAN and are compiled as MEX-files (Mex for Matlab executable) using the
mex utility, they are dynamically liked into Matlab when needed [3].
S-functions use a special calling syntax that enables the programmer to
interact with Simulink equation solvers. This interaction is very similar to the
interaction that takes place between the solvers and built-in Simulink blocks. The
43
form of an S-function is very general and can accommodate continuous, discrete and
hybrid systems. S-functions allow you to add your own blocks to Simulink models. By
following a set of simple rules, it can implement the algorithms in an S-function [3].
The main blocks developed in this project – pbusSlave, UDPsend and
UDPreceive – are implemented as S-functions schemes, for more details see
Chapter 6:.
5.3.2: SIMBApro
SIMBApro is a simulation system, developed by Siemens, for simulating
fieldbus devices using Profibus DP/PA protocol. This powerful tool supports simple
inputs/outputs from Profibus slaves as well as dynamic simulation of user defined
complex functions for end devices e.g. motors, valves. The behavior of such devices
can be manipulated using already integrated digital control logic modules. SIMBApro
has been designed for Windows. The simulator provides all the tools for quick
designing and testing of automation projects during factory acceptance tests (FAT).
The SIMBAsys PCI module (SIMBApro’s hardware) can simulate up to 125 DP
slaves at one Profibus DP bus with user selectable transmission rate. The simulation
of Profibus-DP can be carried out using any Profibus master system [4]. The
SimbaSys may be configured to reproduce two independent Profibus channels or
one redundant Profibus link on one PCI card. The usable number of PCI slots
depends on the hardware configuration of the PC. Data transfer between applications
and the SIMBApro PCI hardware is implemented via the API [4].
In our project each channel will be reserved for a master, and then every
remote I/O computer will contain 2 SimbaSys modules that will use 3 channels as
detailed in Figure 14, page 41.
The Figure 16 shows the slave’s configuration in SimbaPro. All the working
slaves and modules at SimbaPro are marked green. The icons get a light green
border when the Profibus device is in data exchange with the master.
SimbaPro has several slaves that are configured and ready to be used in the
software. However, if there is some slave that is not configured in SimbaPro, it is
possible to download the slave’s GSD (General Station Description) file into
SimbaPro and create the slave features to be used in the application.
44
Figure 16: SimbaPro Slave configuration
5.3.3: XML
XML (eXtensible Markup Language) is a flexible data description language
based on a simple ASCII code. XML documents can be exchanged with an
application in a number of ways, for example using TCP/IP or with HTTP over the
internet. XML is important in automation technology for, among other things,
parameter descriptions in DDT, as import and export format for field device
parameters in engineering tools or as a means of vertical integration (data exchange
independent of the operation system used) [12].
With the acceptance of the XML version 1.0 specification as a W3C
Recommendation in 1998, the XML technology was stable for deployment in industry.
Data can be transmitted between different applications, platforms and programming
languages. The application can decide how to process and present the received
data. An XML document can be validated by a parser. This kind of software checks if
the document’s syntax is correct and provides the contained data to the application.
An XML file with a correct syntax that corresponds to the XML specification is
considered well formed.
A problem arises when the receiver of an XML document does not know the
specific syntax. It may be possible, that it cannot understand the specific tags of the
document and therefore be unable to deliver the data to the application. To avoid this
case and to have the possibility to communicate the syntax of XML documents, they
45
can refer to other documents that define the XML document’s structure. These other
documents can either be a Document Type Definition (DTD) or a Schema. If there is
a relation to one of these document syntax specifications, a so-called validating
parser reads the DTD/Schema and checks the XML document against it. Such a
successfully parsed XML document is called valid.
The use of XML formatted configuration file brings several advantages:
• it can represent the most general computer science data structures:
records, lists and trees;
• facilitate the sharing of data across different information systems;
• its self-documenting format describes structure and field names as well
as specific values;
• the strict syntax and parsing requirements make the necessary parsing
algorithms extremely simple, efficient, and consistent;
• simple and easy conversion from excel data structure to XML data.
Due to these advantages the signal configuration file for our project is an XML
file. An overview of the signal parameter list can be seen in section 5.3.3.1:. This file
will be read by the library “SimbaProLib.dll” which is written in C++. It uses the
external library Apache Xerces parser for processing the XML configuration file.
Xerces is a very solid, well-documented library. It is a validating XML parser
written in a portable subset of C++. Xerces-C++ can read and write XML data. A
shared library is provided for parsing, generating, manipulating, and validating XML
documents.
The choice of using a C++ library is regarding some other projects in Marine
Cybernetics that already used Xerces library, so in order to have a standardized
library to add parsing and XML-generation features to the application, this library was
chosen. An alternative would be Expat that is an XML parser library written in C.
More details about “SimbaProLib.dll” can be found on Section 6.6:.
46
5.3.3.1: XML File
The XML file will be structured as follows (for the explanation of each attribute,
see Appendix A):
<?XML version="1.0" encoding="utf-8" ?>
- <SignalConfiguration>
<Signal index="0" address="S000IB0" type="byte" readWrite="read" bias="0.0" scalefactor="1.0" />
<Signal index="1" address="S000IB1" type="byte" readWrite="write" bias="0.0" scalefactor="1.0" />
<Signal index="2" address="S000IF2" type="float" readWrite="read" bias="0.0" scalefactor="1.0" />
<Signal index="3" address="S000IW3" type="word" readWrite="write" bias="0.0" scalefactor="1.0"
/>
</SignalConfiguration>
5.4: Network Data Exchange Using UDP
The UDP Communication Modules are developed in an S-Function Simulink
block, written in C programming language. These blocks handle UDP communication
between the CyberSea Simulator and the remote I/O computers which will have a
Profibus DP/PA slave interface. The Appendix B describes the Requirements
Specification for CyberSea UDP Communication Modules.
In the CyberSea Simulator a single port is used for transmitting data and a
single port is used for reception of data from the remote I/O computer. In the remote
I/O computer a single port is used for reception of data from the simulator, and a
single port is used for transmitting data back to the simulator.
The module consists of 2 blocks:
• UDPsend (client): a Simulink S-function block that sends datagrams
from one process to another.
• UDPreceive (server): a Simulink S-function block that receives
datagrams from one process.
The UDP use a datagram socket in cases where there is only one message
being sent from the client to the server, and only one message being sent back.
47
There is a lot less overhead associated with a datagram socket because connections
do not need to be established and broken down, and packets do not need to be
acknowledged.
Figure 17 shows how the application will be distributed. The CyberSea
Simulator will have 4 UDP send blocks and 4 UDP receive blocks, that will exchange
data with the remote I/O computers. These computers will carry the simulation of the
profibus DP slaves, and they will be connected to the PLC controllers via Profibus DP
link. The network communication will be made by a network switch.
Figure 17: Distribution of the Simulation Application
A network switch is a computer networking device that connects network
segments. Network switches are capable of inspecting data packets as they are
received, determining the source and destination device of that packet, and
forwarding it appropriately. By delivering each message only to the connected device
it was intended for, a network switch conserves network bandwidth and offers
generally better performance than a hub.
5.4.1: The UDP Simulink Diagram for the CyberSea Simulator
The CyberSea Simulator architecture describes the interplay between a
number of different modules that constitutes the simulator system. A customized
48
CyberSea Simulator is built by configuring and interconnecting the required model
components from the CyberSea Library to meet the requirements of the given
application and adding modules such as a graphical user interface for test scenario
management and configuration (Simulation Manager), hardware communication,
data-logging functionality, and post-analysis of simulation results.
The Simulink diagram for the CyberSea Simulator is shown in Figure 18. Each
‘UDPRecive’ block receives the values sent from the ‘pbusSlave’ block. These values
are the input for the CyberSea PowerPlant Module which is a component of the
CyberSea Simulator; its outputs values are sent to the ‘pbusSlave’ block, via
‘UDPreceive’ block.
The second output of ‘UDPRecive’ block displays the number of datagrams
received from the ‘pbusSlave’ block.
Figure 18: Simulink diagram for the CyberSea Simulator
The CyberSea PowerPlant Module transmits the relevant power system
signals to the remote I/O computers, such as status signals, thruster power
consumption and generator power feedback signals. It is possible to simulate all
operational configurations of the power system by changing the positions of the
49
switches, status flags, circuit breakers, and bus-ties during simulation. It is also
simulated relevant power system failure modes, with respect to single point and
common mode failures, and if relevant, multiple failures. This includes loss of diesel
generators, partial blackout on medium and high voltage switchboards, UPS failures
influencing available position reference systems, sensors and computers, increased
loads on other consumers, and various signal failures on status, command and
feedback signals between power system and DP computer system.
The yellow block is the real-time clock synchronization block. This block
delays the execution of the simulator program in order to synchronize the completion
of this block with the real-time clock. The desired completion time is computed as a
constant time increment (the user-defined synchronization interval) after the previous
desired completion time. The first time the block is executed the desired completion
time equals the real-time clock, i.e. immediate completion. In essence, this block
makes the simulator operate in real time, with specified synchronization interval.
5.4.2: The UDP Simulink Diagram for the Remote I/O Computer
The Simulink diagram for the remote I/O computers is shown in Figure 19. The
‘UDPreceive’ block receives the values sent from the CyberSea Simulator. These
values are the input for the pbusSlave; its outputs are Profibus’ slave values
(configured in SimbaPro software), that will be sent to the CyberSea Simulator, via
‘UDPreceive’ block.
The second output of ‘UDPRecive’ block displays the number of datagrams
received from the CyberSea Simulator.
Figure 19: Simulink diagram for the remote I/O computers
50
The second output of ‘pbusSlave’ block verifies the status of the SimbaPro
software (checks if it is opened or not).
The yellow block is the real-time clock synchronization block, more information
in Section 5.4.1:.
5.5: Validation of the Modules
After the implementation of the S-function blocks, a test phase follows in order
to validate the modules. Three types of tests were executed to verify if all
requirement specifications defined in Appendix A and Appendix B were fulfilled:
• Self_test: these tests were carried out without sending data out of the
computer but by means of the loopback device IP: 127.0.0.1. Two
Simulink applications were used: UDP_SimbaPro.mdl and
UDP_Simulator.mdl, the first one is the remote I/O computer, and the
second emulates the CyberSea PowerPlant Simulator.
• Simulator: the remote I/O computer has the Profibus DP/PA Slave
module and communicates with the CyberSea PowerPlant Simulator
via UDP/IP. The UDP receive block which receives datagrams from the
remote I/O computer, and the UDP send block which sends data to the
remote I/O computer were inserted into the CyberSea PowerPlant
Simulator.
• No explicit test: these requirements are basic function-points that have
been tested continuously in the development phase.
The tests were developed using:
• simulator PC runtime computer: Windows XP SP2;
• remote I/O PC runtime computer : Windows XP SP2;
• Matlab version: 7.4.0.287 (R2007a).
The tested modules are:
• UDPSend.c;
• UDPReceive.c;
51
• pbusSlave.cpp.
5.5.1: Simulator Test
The CyberSea PowerPlant Simulator sent 2945 signals via UDP/IP to the
remote I/O computer, but only 4 signals were written to the slaves’ modules. The
remote I/O computer sent 739 signals to the CyberSea PowerPlant Simulator,
however only 5 signals were read from the slaves’ modules. These fixed number of
signals are a specification from the CyberSea PowerPlant Simulator, which sends a
fixed vector of 2945 signals, and receives a fixed vector of 739 signals.
Although having this large overhead of signals, the priority here is the
generality of the blocks and the simplicity of the simulation. It was checked by
simulation that the cycle time is only influenced by the amount of data to be written or
read to/from the SimbaPro module. The data exchange via UDP is quite fast, less
than 10μs. So we did not developed other functionalities or blocks to send or receive
the exact amount of signals. For that, it would be required to change the UDP blocks
of the CyberSea PowerPlant Simulator, or to create 2 new blocks, that would read
the XML file, in order to get the exact number of signals to be sent to the remote I/O
computer, and in order to recreate the super vector necessary to the CyberSea
PowerPlant Simulator. And this approach would also create some overhead regard
reading an XML file twice and manipulating its values.
5.5.1.1: Simulated Signals
For the Simulator test, 9 signals were used, 4 of them were sensor signals, i.e.
values to be written into the slave modules, type ‘write’ in the XML file; and 5 were
actuator signals, i.e. values to be read from the slave modules, type ‘read’. The bias
was equal to 0 and the scale factor was equal to 1. The signal description and type
are described below.
• Type write – Sensor Slave Device
o Generator 1 Running: digital;
o Engine Ready: digital;
o Engine In Remote: digital;
52
o Active Power: analog (float).
• Type read – Actuator Slave Device
o Stop Engine: digital;
o Start Engine: digital;
o Generator 1 Circuit Breaker Open: digital;
o Generator 1 Circuit Breaker Close: digital;
o Thruster 1 Power Limit: analog (float).
5.5.1.2: Results of Simulator Test
All the test requirements specified in Appendix A and Appendix B were
checked by simulation and all the requirements were fulfilled. The sample time used
for all blocks was 100ms, according to the specified cycle time for the Profibus DP
bus. The cycle time for this Simulator Test was 16ms with an average CPU usage for
the remote I/O computer of 4%.
The Figure 20 shows the Simulator interface, the simulated signals have a
dashed rectangle. The correct values from the sensor devices were read by the
SimbaPro module, and the exact values were written to the Simulator. We could stop
and start the engine, as well as open close the circuit breaker. The power limit set for
the Thruster 1 was 20KW.
5.5.2: Self-Test
Another accomplished test, self-test, dealt with 734 signals being sent or
received from/to the SimbaPro slaves’ modules (3 Kbytes). The sample time used in
all blocks were 100ms. The maximum cycle time was 47ms with an average CPU
usage of 10%. All the test requirements specified in Appendix A and Appendix B
were checked by simulation and all the requirements were fulfilled.
53
Figure 20: Simulator’s interface for Simulator Test
5.5.3: Results of Testing Phase
All validation tests were successfully accomplished and well integrated into the
CyberSea library. The rate of data exchange for the maximum amount of signals
being transmitted is less than 10μs and it is below the required sample time for the
Profibus communication, which is 100ms.
The real test with the power management system of the drilling vessel will deal
with approximately 400 signals. The developed application to read and write values
54
to/from slaves and to exchange data with the CyberSea PowerPlant Simulator will
complete its task in the appropriate sample time, as confirmed by the tests.
These blocks are common blocks and they can be used for other projects that
requires UDP communication or simulation of Profibus slaves. They are integrated
into the Matlab as a typical Simulink block, and built up in the application by drag and
drop.
The UDP blocks were programmed in a general way so they can be used to
exchange datagrams between any applications.
We did not perform the factory acceptance test so far, it is dated to November
of 2007.
55
Chapter 6: Programming of the S-Function Blocks
This chapter will embrace important programming aspects of the 3 main S-
functions implemented in this project: UDPreceive, UDPsend and pbusSlave,
including all the libraries used.
First an overview of the Simulink simulation stages will be made, also
exploring the main callback methods used in programming the S-functions.
6.1: Simulation Stages
Execution of a Simulink model proceeds in stages. First comes the
initialization phase. In this phase, Simulink incorporates library blocks into the model,
propagates widths, data types, and sample times, evaluates block parameters,
determines block execution order, and allocates memory. Then Simulink enters a
simulation loop, where each pass through the loop is referred to as a simulation step.
During each simulation step, Simulink executes each of the model's blocks in the
order determined during initialization. For each block, Simulink invokes functions that
compute the block's states, derivatives, and outputs for the current sample time. This
continues until the simulation is complete [3].
The Figure 21 illustrates the stages of a simulation, each step is explained
below.
1. Initialization: prior to the first simulation loop, Simulink initializes the S-
function. During this stage, Simulink:
• initializes the SimStruct, a simulation structure that contains information
about the S-function;
• sets the number and dimensions of input and output ports;
• sets the block sample times;
• allocates storage areas.
2. Calculation of next sample hit.
56
3. Calculation of outputs in the major time step: after this call is complete, all
the output ports of the blocks are valid for the current time step.
4. Update of discrete states in the major time step: in this call, all blocks
should perform once-per-time-step activities such as updating discrete
states for next time around the simulation loop.
5. Integration: this applies to models with continuous states and/or
nonsampled zero crossings.
Figure 21: Stages of a Simulink simulation
6.2: S-Function Callback Methods
Every user-written S-function must implement a set of methods, called
callback methods that Simulink invokes when simulating a model that contains the S-
function. Some callback methods are optional, Simulink invokes them only if the S-
function defines the callback.
57
The purpose of the callback methods used on the implemented S-functions
are explained as follows:
1. mdlCheckParameters: optional method. It verifies new parameter settings
whenever parameters change or are reevaluated during a simulation.
2. mdlInitializeSizes:
• specifies the number of inputs, outputs, states, parameters, and other
characteristics of the s-function;
• specifies the number of parameters that the s-function supports;
• specifies the number of states that the s-function has;
• configures the block's input ports. this entails the following tasks:
o specifies the number of input ports that the s-function has;
o specifies the dimensions of the input ports;
• configures the block's output ports. this entails the following tasks:
o specifies the number of output ports that the block has;
o specifies the dimensions of the output ports;
• sets the number of sample times (i.e., sample rates) at which the block
operates;
• sets the size of the block's work vectors.
3. mdlInitializeSampleTimes: specifies the sample rates at which this S-
function operates.
4. mdlStart: optional method. It initializes the state vectors of the S-function.
5. mdlOutputs: computes the signals that this block emits. Simulink invokes
this required method at each simulation time step. The method should
compute the S-function's outputs at the current time step and store the
results in the S-function's output signal arrays.
6. mdlTerminate: performs any actions required at termination of the
simulation. This method should perform actions like freeing memory that
58
must be performed at the end of simulation or when an S-function block is
destroyed (e.g., when it is deleted from a model).
6.3: UDP Send Block
This block sends UDP messages with a given number of real signals at a
user-specified rate to a given destination (IP) and port. Below it is a brief explanation
of the block’s implementation with the callback methods and functions.
1. mdlCheckParameters checks:
• if all parameters are real positive vectors;
• if the port number is between the limits of 1025 to 65535;
• if the size of the data vector is under the maximum limit.
2. mdlInitializeSizes: checks the number of parameters and then calls
mdlCheckParameters to see if they are satisfactory.
3. mdlInitializeSampleTimes: initializes sample time.
4. mdlStart:
• checks if the UDP send block is enabled;
• activates the Winsock DLL;
• calls the function StartUDPClient().
5. StartUDPClient():
• starts the client;
• calls the function netClientInit() which will create the socket.
6. SOCKET netClientInit():
• clear the structure to avoid garbage;
• creates a socket for sending data;
• sets up the destination structure with the IP address of the destination
and the specified port number.
59
7. mdlOutputs:
• checks if the UDP send block is enabled;
• transmits data – sendto();
• reports error if cycle time is greater than the sample time.
8. mdlTerminate:
• checks if the UDP send block is enabled;
• deallocates the socket;
• calls the function WSACleanup().
6.4: UDP Receive Block
This block receives UDP messages with a given number of real signals at a
user-specified rate to a given destination (IP) and port. Below it is a brief explanation
of the block’s implementation with the callback methods and functions.
1. mdlCheckParameters checks:
• if all parameters are real positive vectors;
• if the port number is between the limits of 1025 to 65535;
• if the size of the data vector is under the maximum limit.
2. mdlInitializeSizes: checks the number of parameters and then calls
mdlCheckParameters to see if they are satisfactory.
3. mdlInitializeSampleTimes: initializes sample time.
4. mdlStart:
• checks if the UDP receive block is enabled;
• activates the Winsock DLL;
• calls the function StartUDPServer.
5. StartUDPServer ():
• starts the server;
60
• calls the function netClientInit().
6. SOCKET netClientInit():
• clear the structure to avoid garbage;
• creates a socket for sending data;
• associates the source socket's address with the socket.
7. mdlOutputs:
• checks if the UDP receive block is enabled
• receives data and store it in the buffer – recv();
• reports error if cycle time is greater than the sample time.
8. mdlTerminate:
• checks if the UDP receive block is enabled;
• deallocates the socket;
• calls the function WSACleanup().
6.5: pbusSlave Block
The block sends and receives data to/from Profibus DP/PA compatible unit.
Below it is a brief explanation of the block’s implementation with the callback
methods and functions. The (*) refers to functions implemented on the SimbaProLib
library, which are detailed in the section 6.6:.
1. mdlCheckParameters checks if:
• number of parameters to the S-function match the expected number;
• parameters to the S-function are of the correct type (integer or string).
2. mdlInitializeSizes: checks the number of parameters.
3. mdlInitializeSampleTimes: initializes sample time.
4. mdlStart:
61
• the static create function calls the private constructor SimbaProIni*
(section 6.6.3.1:, page 64);
• gets instance of SimbaProIni*;
• SIMBA2_OpenProject()*: Opens SimbaPro project, checks if SimbaPro
is opened correctly, connects simulation modules in the current project,
downloads the hardware configuration of the current project into the
simulation module;
• the static close function calls the private destructor SimbaProIni*;
• checks SimbaPro status (if the software is opened or not);
• the static create function calls the private constructor
CSIMBAPROLib_Receiver*;
• the static create function calls the private constructor
CSIMBAPROLib_Sender*;
• gets instance of CSIMBAPROLib_Sender* (section 6.6.3.1:, page 64);
• gets instance of CSIMBAPROLib_Receiver* (section 6.6.3.1:, page 64);
• sender->readConfiguration()*: reads the XML file, gets the attributes of
the nodes and store into the hash_map;
• receiver->readConfiguration()*: reads the XML file, gets the attributes of
the nodes and stores it into the hash_map.
5. mdlOutputs:
• checks if the UDP receive block is enabled
• get instance of CSIMBAPROLib_Sender*;
• get instance of CSIMBAPROLib_Receiver*;
• sender->getSendValuesPointer()*: gets the pointers to the values to be
sent;
• receiver->getReceivedValuesPointer()*: gets the pointers to the
received values;
62
• sender->sendSignals()*: sends the received value to the corresponding
slave;
• receiver->readSignals()*: receives the value from the corresponding
slave;
• reports error if cycle time is greater than the sample time.
6. mdlTerminate:
• checks if the UDP receive block is enabled;
• the static create function calls the private constructor SimbaProEnd*
(section 6.6.3.1:, page 64);
• the static close function calls the private destructor
CSIMBAPROLib_Sender*;
• the static close function calls the private destructor
CSIMBAPROLib_Receiver*;
• the static close function calls the private destructor SimbaProEnd*.
6.6: Implementation of SimbaProLib Library
All configuration functionality exists in the SimbaProLib library, and the S-
function pbusSlave is kept as simple as possible. The library SimbaProLib.dll will be
dynamically linked during start-up of the simulator.
All modules are written in C++ and have been coded and compiled using
Microsoft Visual Studio 2005. Configuration of the library is done by reading of an
XML formatted configuration file. Figure 15, on page 42 shows how the library is
structured.
6.6.1: External Dependencies
• XML-Parser: SimbaProLib uses xerces-c_2_7.dll external library for
processing of the XML configuration file (for more information about Xerces
C++ library see section 5.3.3:);
63
• “SimbaKern.dll”: it is the API interface of the SimbaSys module. It has
commands to access Simba modules from applications other than
SimbaPro.
6.6.2: Internal Dependencies
• CyberSeaMessages: the library and the S-functions use CyberSeaMsgDLL
to display Debug and Error information.
6.6.3: Library Architecture
A UML Class diagram for the SimbaProLib Library is shown in Figure 22. The
classes are explained below.
6.6.3.1: SimbaProLib_API
The Library provides as an interface four singleton classes:
1. SIMBAPROLib_Sender:
• reads the XML configuration file;
• checks which slave address has the function type ‘write’;
• receives from the input of the pbusSlave S-function block the data to be
written into the slave;
• uses the SimbaPro function (API interface of Simbakern.dll) to write the
data into the appropriate slave.
2. SIMBAPROLib_Receiver:
• reads the XML configuration file;
• checks which slave address has the function type ‘read’;
• uses the SimbaPro function (API interface of Simbakern.dll) to read the
data from the appropriate slave;
• sends the read data value as an output of the pbusSlave S-function
block.
64
3. SimbaProIni:
• opens the project file;
• checks if the project was correctly opened;
• connects all the simulation modules and loads the hardware
configuration of the current project into the simulation module;
• extra function: activates or deactivates one single slave;
• sets the Baudrate of the SimbaPro simulation.
4. SimbaProEnd:
• disconnects all simulation modules;
• closes the project.
6.6.3.2:
6.6.3.3:
SimbaProDLL_Loader
To access the functions of SimbaPro API (SimbaKern.DLL), we had to use a
function call to explicitly load the DLL at run time (SimbaPro did not have any header
or library file to directly call its API functions). The class SimbaProDLL_loader
explicitly links the DLL, for that it calls:
• LoadLibrary to load the DLL and obtain a module handle;
• GetProcAddress to obtain a function pointer to each exported function
that the application wants to call. Because applications are calling the
DLL's functions through a pointer, the compiler does not generate
external references, so there is no need to link with an import library;
• FreeLibrary when done with the DLL.
Builder
The Builder class reads the hash_map signal that has the function type “write”,
it gets the address of the corresponding slave and write the received data to that
slave using SimbaPro writing function.
The hash_map is a class that stores and retrieves data quickly from a
collection in which each element is a pair that has a sort key and an associated data
65
value. The sort key is a unique value, in this application it is the address of the slave.
Looking up an element in a hash_map by its key is efficient, so hash_map is useful
for "dictionaries" where the order of elements is irrelevant, as in our case [17].
6.6.3.4:
6.6.3.5:
6.6.3.6:
Parser
The Parser class reads the hash_map signal that has the function type “read”,
it gets the address of the corresponding slave and reads the data from that slave
using SimbaPro reading function.
CSIMBAPROLibConfiguration
The CSIMBAPROLibConfiguration class reads the XML configuration file
using the Xerces C++ library. It calls a method to request a DOM (Document Object
Model) implementation, creates a new DOMBuilder, which provides an API for
parsing XML documents and builds the corresponding DOM document tree. It parses
via a file path, and gets the first child of each node. After that it gets all the attributes
of the node, and it reads each collection of the node’s attributes. Finally it adds these
attributes to the hash_map.
The DOM is an application programming interface (API) for HTML and XML
documents. It defines the logical structure of documents and the way a document is
accessed and manipulated. With the DOM, programmers can build documents,
navigate their structure, and add, modify, or delete elements and content. Anything
found in an HTML or XML document can be accessed, changed, deleted, or added
using the DOM [18].
CSignal
The CSignal class will configure the gets and sets for each attribute configured
in the XML file. The CSIMBAPROLibConfiguration class will store each attribute’s
values calling the methods defined in the CSignal class.
66
Figure 22: SimbaProLib.dll UML diagram
67
Chapter 7: Conclusions and Perspectives
In this project we have presented the implementation of a Profibus
communication interface between the CyberSea Simulator and the power
management system of a drilling vessel.
The student developed a Fieldbus interface solution to be used in Marine
Cybernetics’ Hardware-In-the-Loop Simulator for the purpose of testing control
systems installed on ships and offshore floating platforms. In particular, solutions for
the distributed simulation of a large number of Profibus slaves in the simulator
architecture. The project was successfully specified, developed, tested and
documented according to the quality system of the company and good industrial
practices.
The need for testing on marine control system is becoming more important
since a large and increasing part of the costs for a new ship or offshore installation is
due to computer controlled systems. Hardware-in-the-Loop is a methodology tool
which is gaining importance for testing a controller's functionality and communication.
HIL technology is used in the development and testing of computer control systems.
The CyberSea Simulator is a technology developed by Marine Cybernetics based on
HIL testing.
The presented Profibus communication interface simulated Profibus DP
slaves, using SimbaPro PCI card, in order to simulate the functionality of the power
management system of the vessel. SIMBApro PCI enables all kinds of Profibus
elements to be simulated, from distributed peripherals to a complete real-time
simulation of the plant and process. It simulates the response of peripherals on the
field bus.
The Profibus communication interface is composed by an S-function block
written in C++ programming language, with several modules. The purpose of the
communication interface is to simulate the Profibus slave devices, and to read and
write data from/to these slaves. The modules have distinct functions to accomplish,
which include commissioning of the SimbaPro hardware and software, displaying of
68
debug and error information and reading of the slaves addresses in an XML
configuration file.
The PMS control system was formed with 4 remote I/O computers connected
via Profibus DP to a SIMATIC S7-400 PLC. The computer networking was composed
by these 4 remote I/O computers connected to the CyberSea Simulator through a
switch. There are UDP receive and send S-function blocks that allow exchanging
data via an UDP/IP connection between Simulink schemes running in the simulator
and in the remote I/O computers.
All testing and validation were accomplished successfully and the new
configured blocks are inserted into the CyberSea library. With this application we
have a standard tool for a Profibus communication interface which can be used in
other projects that employ the same technology, it is also a common tool for
interfacing controllers from different vendors. The excellent re-usability of the blocks
means a minimized development cost.
The solution quickly and easily implement a communication infrastructure, it
minimizes the implementation and acquisition costs. It lies in effective software and
enables fast integration of industrial communication to a simulator environment.
As future work proposals we can mention the use of SIMBApro in DP HIL
projects, and the development of a common communication interface, including
configuration and functionality independent of protocol.
As personal conclusion, the amount of knowledge and most of all, life and job
experience achieved with the internship represent a great gain. The participation in a
group multi-task project, attending to meetings, writing specification reports and
respecting dead-lines were important to the improvement of the student, successfully
completing this learning phase.
69
Bibliography:
[1] PI International, “PROFIBUS Technology and Application – System, October
2002”, http://www.profibus.com/, date 28/04/2007.
[2] PI International, “PROFIBUS“, http://www.profibus.com/pb/, date 26/04/2007.
[3] The MathWorks Inc., “Writing S-Functions – Model-Based and System-Based
Design”, Version 5, Natick, USA, 2002.
[4] Siemens AG, ”Siemens SIMBApro V5 – Online Manual”, Karlsruhe, Germany,
2007.
[5] EGELAND, O. and GRAVDHAL, J.T., “Modeling and Simulation for Automatic
Control”, Marine Cybernetics, 2002.
[6] KUNDUR, P., “Power System Stability and Control”, Electric Power Research
Institute, editor McGraw-Hill, Inc 1994.
[7] FALTINSEN, O.M., “Sea Loads on Ships and Offshore Structures”, Cambridge
University Press, 4th edition, 1999.
[8] HANSEN, J.F., “Modeling and Control of Marine Power Systems”, Doctor
thesis, Norwegian University of Science and Technology, Department of
Engineering cybernetics, Trondheim, Norway, 2000.
[9] International Maritime Organization (IMO), “Guidelines for Vessels with
Dynamic Positioning Systems,” Maritime Safety Committee (MSC) Circular
645, June 1994.
[10] SKJETNE, R. and EGELAND, O., “Hardware-in-the-loop Testing of Marine
Control Systems”, Marine Cybernetics AS, Trondheim. SIMS 2005, 46th
Conference on Simulation and Modeling, TRD, October 2005.
[11] “Shipping Information and Solent Ports”, http://www.solentwaters.co.uk/
Vessel%20Types/Vessel%20Types%204/page7.html, date 25/07/2007.
[12] DEITEL, H. M., ”Web Services: A Technical Introduction”, Prentice Hall, Upper
Saddle River, New Jersey, 2003.
70
[13] POPP, M., “The New Rapid Way to Profibus DP, from DP-V0 to DP-V2.“
Profibus Nutzerorganisation e.V., Germany, 2003.
[14] Hilscher Competence in Communication, “Protocol Manual – Profibus-DP”,
Germany, 1999.
[15] TANENBAUM, A.S., “Computer Networks”, 4th Edition, Prentice Hall, 2002.
[16] Siemens, “Functional Design Specification PMS – Drilling Unit”, 01/02/2007.
[17] Visual C++ Developer Center, “Standard C++ Library Reference
<hash_map>”, http://msdn2.microsoft.com/en-
us/library/6x7w9f6z(VS.80).aspx, date 08/08/2007.
[18] “Oracle8i XML Reference Guide”, Release 3 (8.1.7), Part Number A83730-01,
http://www.usd.edu/oracle/doc/appdev.817/a83730/arx06pac.htm, date
08/08/2007.
71
Appendix A: Requirements Specification for CyberSea Profibus DP/PA Slave module
The Appendix A describes in more details how the pbusSlave S-function block
is modeled, its parameters, inputs, outputs and warning messages. It presents the
functional and test requirements for CyberSea Profibus DP/PA Slave module.
A.1: Block inputs, outputs, and masked parameters
The pbusSlave block is used to send data to a Profibus DP/PA compatible unit
and receive data from the unit. The block will build and send the data with values
taken from the input vector and it will receive and parse data and output values into
the output vectors. The data is configured based on the XML configuration file
(section 5.3.3:).
A.1.1: Input signals
The block inputs one vector which holds all values transmitted to the PLC
controller. The vector size is equal to the size of data vector defined in the mask. The
input data vector to be sent to the SimbaPro is initialized to zero for every element
and only entries configured for send values will be updated.
• Simulink data vector (values to be sent to the slaves) 1 x m Real
A.1.2: Output signals
The block has two outputs. One is a vector which holds all values received
from the configured slaves. The vector size is equal to the size of data vector defined
in the mask. The output data vector is initialized to zero for every element and only
entries configured for reception from the PLC controller will be updated. The second
output verifies the status of the SimbaPro software (checks if it is opened).
• Simulink data vector (values received from the slaves) 1 x m Real
72
• SimbaPro program Connection status 1 x 1 Real
A.1.3: Masked Parameters
Mask parameter text Data type Description Internal parameter
name
Profibus SimbaPro
file name
1 x 256 String Path to SimbaPro
configuration file (folder
with ending .spf)
fileNameSimbaPro
Profibus XML Signal
file name
1 x 256 String Path to XML
configuration file
filename
Size of input data
vector
1 x 1 Real Size of input data vector SIZE_DATA_IN
Size of output data
vector
1 x 1 Real Size of output data
vector
SIZE_DATA_OUT
Profibus Sample
Time
1 x 1 Real Sample time of the block SAMPLETIME
Baudrate (0= do not
change / 6= 1,5MBd
/ 7= 3MBd / 8= 6MBd
/ 9= 12MBd)
1 x 1 Real Set the Baudrate of
SimbaPro channels
BAUDRATE
Number of channels
in SimbaPro
1 x 1 Real Number of channels in
SimbaPro in order to
change the baudrate
CHANNEL
Enable SimbaPro
simulation
1 x 1 Real Flag to enable/disable
the operation of this
block
ENABLE
Table 7: Masked parameters for pbusSlave block
73
A.1.4: Parameters of the XML file read in “SimbaProLib.dll”
Mask parameter text Data type Description
Profibus Signal Index
int Signal indices (relative to the Simulink super
vector).
Profibus Signal Address char Array with Profibus signal addresses (e.g.
S000ID1, the index starts with ‘S’, followed by
triple-digit number taken from the hardware
view, and the IO notation: I (input), Q (output);
followed by (addresses determined by the
programmer): x.y (bit), Bx (byte), Dx (double),
Wx (word), Fx (float).
Profibus Function
ReadWrite
char Array with Profibus functions name: ‘read’,
‘write’.
Profibus Signal Type char Array with Profibus type for each signal: ‘bit’,’
byte’, ’word’, ’double’, ’float’.
Profibus Signal Bias float Bias for each signal.
Profibus Signal Scale float Scaling for each signal.
Table 8: XML initialization file parameters
A.1.5: Inherent failure modes
The block has no failure modes.
A.1.6: Warning/error messages
If there is a problem with the socket initialization a CyberSea error message is
provided.
74
A.2: Functional requirements
1. Physical communication shall be possible with any Profibus DP/PA
interface.
2. Any Profibus DP/PA slave shall be inserted into the project.
3. Each channel shall support up to 125 slaves.
4. It shall be possible to configure several SimbaSys PCI modules, using only
one configuration file in SimbaPro. No more than one S-function block shall
be required.
5. The input configuration data shall be specified in a consistent and
unambiguous way. The conversion of the Excel data into the necessary
and required XML data will be taken directly from the Microsoft Excel
program.
6. The transmission rate should be possible to be changed in configuration.
7. Transmission errors, network errors, or Profibus protocol errors shall not
delay or hang up the communication module. The module shall issue an
error message with the CyberSea Message function in such cases.
8. Each signal in the network shall be specified in the XML Signal file. The
parameters that are going to be configured are: index, address, read or
write function, type, bias, and scale-factor.
9. The SimbaPro configuration filename, the XML file name, the size of the
input and output data vector, the sample time, the baudrate, the number of
channels of the SimbaPro project and the enable/disable functionality shall
be specified in the mask of the module.
10. Different Profibus functions must be supported. The following shall be
supported:
• read (read value from slave);
• write (write value to slave);
11. Different types of signals must be supported. The following shall be
supported:
75
• bit;
• byte;
• double word;
• word;
• float.
12. Enabling and disabling of execution shall be configurable in the masked
parameter. Simulator shall run even with module disabled.
13. The function ActivateSlave is implemented; however it has to be
uncommented in the S-function code in mdlStart to be used.
14. The block shall indicate connection status of SimbaPro program on an
output port.
A.3: Test requirements
The module should be tested according to the following requirements:
1. The Profibus DP/PA Slave module should be connected to the
corresponding Master (SimbaPro and the Master have to have the same
modules and offset/address), and its connection should be verified (Master:
debug mode; SimbaPro: light green border when the PROFIBUS device
is in data exchange with the master).
2. The transmission rate should be tested for at least 2 different values:
Simulator frequency and 0.1s (minimum rate for the UDP receive block).
3. Different signals should be sent and received to/from the slave modules to
verify that the system configuration and programmed functions are
adequate.
4. If the SimbaPro program is not opened, the status in the output port of the
pbusSlave should be zero.
5. If the SimbaPro program is closed during operation, the status in the output
port of the pbusSlave should be set to zero. (To run SimbaPro again, you
76
have to stop the simulation, close Matlab, then open SimbaPro and Matlab
again. If you reopen SimbaPro without closing Matlab, Matlab will crash.)
6. The CyberSea Simulator should run with the block disabled. The block
shall not hang the simulator.
7. If the pbusSlave is disabled, the status in its output port should be zero.
8. All Profibus data-table formats should be sent and received and verified
with a Slave device.
9. For testing the function ActivateSlave, first uncomment the code in
mdlStart. To check if the slave was deactivated, verify if it has red stripes
on the slave module in SimbaPro.
77
Appendix B: Requirements Specification for UDP Modules
The Appendix B describes in more details how the UDPreceive and UDPsend
S-function blocks are modeled, their parameters, inputs, outputs and warning
messages. It presents the functional and test requirements for CyberSea UDP
modules.
B.1 UDP receive block
This block is used to receive data from the remote I/O computer (which is
connected to the PLC controller) or from the CyberSea Simulator. The block will
receive data, and set the received values in the output vector.
B.1.1 Masked parameters
Mask parameter
text
Data type Description Internal
parameter name
IP address of host
network interface
card
1 x 1 String (e.g.
192.168.168.140)
IP address of host
network interface card
ipAddrNIC
UDP port 1 x 1 Real UDP port number port
Size of data vector 1 x 1 Real Size of the received
data vector
bufsize
Sample time 1 x 1 Real Block’s sample time SAMPLETIME
Enable UDP
simulation
1 x 1 Real Flag to enable/disable
the operation of this
block
ENABLE
Table 9: Masked parameters for UDP receive block
78
B.1.2 Output signals
The block has two outputs. One is a vector that holds all values received. The
vector size is defined in the mask. The second output display the number of
datagrams received (doubles).
• Simulink data vector (values received from the slaves) 1 x m Real
• Number of received data (should be the same as the buffer size)1 x 1Real
B.1.3 Failure modes
The block has no failure modes.
B.1.4 Warning/Error messages
• If there is a problem with socket initialization a CyberSea error message is
provided.
• If the socket bind fails a CyberSea error message is provided.
• If the data is not received correctly a CyberSea error message is provided.
• If the processing of data is too slow a CyberSea error message is provided.
B.1.5 Comments on implementation
The UDPreceive code will try to read all datagrams available on the socket
every step. A performance check function will give a warning if processing of the data
is not fast enough. The function measures the time to process the buffer available on
the socket compared to the block's step time. Since the simulator is running in real-
time it should be able to empty the buffer faster than the step size. If the code is not
able to empty and process the buffer in time, the code will return and output a
warning message. By that the simulator process will not be haltered.
B.2 UDP Send Block
This block is used to send data to the remote I/O computer or to the CyberSea
Simulator.
79
B.2.1 Input signals
The input vector holds all values to be sent to the slaves. The vector size is
equal to the buffer size defined in the mask.
• Simulink data vector (values transmitted to the slaves) 1 x m Real
B.2.2 Masked parameters
Mask
parameter text
Data type Description Internal
parameter name
IP address of
destination
1 x 1 String (e.g.
192.168.168.140) IP address of hostname host
IP address of
host network
interface card
1 x 1 String (e.g.
192.168.168.140)
IP address of host network
interface card
ipAddrNIC
UDP port 1 x 1 Real UDP port number port
buffer size 1 x 1 Real Buffer size of the received
data
bufsize
Sample time 1 x 1 Real Sample time of the block dSampleTime
Enable UDP
simulation
1 x 1 Real Flag to enable/disable the
operation of this block
ENABLE
Table 10: Masked parameters for UDP send block
B.2.3 Failure modes
The block has no failure modes.
B.2.4 Warning/error messages
• If there is a problem with the socket initialization a CyberSea error
message is provided.
• If the data is not sent correctly a CyberSea error message is provided.
80
• If the processing of data is too slow a CyberSea error message is
provided.
B.2.5 Comments
The UDPsend code will try to write all datagrams available on the socket every
step. A performance check function will give a warning if processing of the data is not
fast enough. The function measures the time to process the buffer available on the
socket compared to the block's step time. Since the simulator is running in real-time it
should be able to empty the buffer faster than the step size. If the code is not able to
empty and process the buffer in time, the code will return and output a warning
message. By that the simulator process will not be haltered.
B.3 Functional requirements
1. Data should be sent with a rate of at least 10 Hz.
2. Data should be received at any rate up to 10 Hz.
3. It should be possible to receive and send any selection of signals in the
Simulink signal bus. The set of signals should be configurable.
4. The IP addresses of the computer NIC connected to the PLC controller and
the MC computer NIC should be configurable. Port number should also be
configurable.
5. The UDP send and UDP receive modules should be implemented such
that one of them does not lock the socket communication and prevent the
other module from using it. As a result testing the module should be
feasible without an existing network by applying the loopback device
(127.0.0.1).
6. Successful and unsuccessful configuration should be reported using the
CyberSea Message functionality.
81
7. The size of the output vector should be set by the user in the block’s mask.
The maximum size of the output vector is the Simulink signal bus size
(4096). The output vector should be initialized to zero when no data is
received.
8. Communication problems or loss of contact with the MT computer should
not stop or delay the execution of the simulator.
9. Enabling and disabling of execution shall be configurable in the masked
parameter. Simulator shall run even with module disabled.
10. In case that datagrams are not received in the UDPreceive block, the last
values stored in that block shall not be deleted, so the simulator does not
hang.
B.4 Test requirements
The module should be tested according to the following requirements:
1. The send module should be tested and verified to be capable to send data
at (500 signals ~16 kB) 10 Hz.
2. The receive module should be tested and verified to be capable to receive
data (500 signals ~ 16 kB) at 10 Hz.
3. The Simulator application and the remote I/O computer application should
be running, and then one of them should be stopped. It should be verified
in the output display of the UDPreceive block that the last values received
are stored its output vector.
4. It should be tested that a warning is provided if the socket buffer is not
emptied every sample time due to overload.
82
