Introduction of the microprocessor technique in the

marine industry
Are you aware of the consequences?

MOST SW IS NOT POSSIBLE TO VERIFY WITH TESTING

• Most PLC or Microprocessor programs is not possible to verify with even the most
complex and thorough test system or algorithms you can find

A mothern vessel contains 10 000-50 000 parameters

• One singel parameter change may cause the vessel to suffer critical damage
 Page 3

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

Do you have answers to this simple questions:

• How many microprocessors are installed in your vessel?
• In what systems are there a microprocessor?
• Do you believe the SW functions are 100% verifyed after a test?
• Is it possible that your vessel could be off-fhire caused by a single CPU failure?
• Does the crew have the neccesary tools and skills to rectify any CPU problem?
• Do you keep a Spare Copy of the SW?
• Do you keep a Parameter backup?
• Do you keep all Spareparts?
• Do you know the Firmvare Versions?
• Do you have Upload possibilities on board?

Facts:
• The number of computer systems on a vessel is today UNKNOWN
• Consequences of a failure of these systems are UNKNOWN
• Computer problem is the increasing source for vessel off-hire
• A 100 dollar PLC may “bring down” a 100 million dollar state-of-the-art vessel
• Most ship owners does not have any clue about the SW and parameters onboard
• Number of parameters may rise to 30-50 000 on a single vessel!
• One faulty parameter may cause a critical accident
• Reset is commonly used as the first attempt to fix a problem

Ship owner’s reports:

• Huge increase in unexplained events of different equipment, sometimes with serious damage
• The number of “sub control systems” is increasing and creating huge challenges
• Difficult to recreate the problem, in order to find the bug
• The crew is searching blindly in the system for the cause of an event, and desperately looking for
some reason and actions to report
• Systems need a long and troubling commissioning period, before they are performing to a minimum
• The crew now often accepts poor systems if they can get around the problem
• The occurrence of critical side effects after an SW upgrade has become common, therefore systems
with poor performances and known bugs are accepted as long as possible
• Nobody has the full knowledge of a modern computer system
• System upgrade has become a real challenge, and sometimes a nightmare
• Replacement of computer part from stock has become almost impossible
 Page 4

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

BACKGROUND

Cheap PLC
The price of a microprocessor or a PLC (Programmable
Logic Controller) has now become so low that the traditional
relay logic is rarely used.
The introduction of this programmable relay controller, have
revolutionized the process control industry in terms of
efficiency and cost-effectiveness.
Control tasks, that earlier could take months to design and
connect with relays, can now be downloaded in a PLC and
executed in a few minutes.
Changes in the logic that earlier had to be reconnected during
a process stop, may now be done in full operation with a key
press, even remotely via the Internet.
The number of programmable controllers has exploded in the
past years, and have now become a standard installation in all kind of equipment onboard a modern vessel.

Few or NONE of the ship owners today have the necessary knowledge to fully understand the
consequences of this relatively small design change among the complex products delivered to the
marine industry.

The modern equipment suppliers have got their own Control System
Due to the fact that all equipment manufacturers now have stepped into the control system world, we see an
explosive increase in number of subsystems in a modern vessel.
The reason is that the price level for a PLC with a VDU is extremely low, and relatively easy to implement.

The result is that the yards purchase the equipment, along with a small control system for this component.

We have now seen this for: Diesel engines, Thrusters, Compressors, Switchboards, Separators, Winches,
Motor drives, Boilers etc., and have accepted this, due to the complexity in the control logic, together with
the demand from the supplier to have full control of his own equipment.
 Page 5

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------
But now this is developing to a level where it will get totally out of control.
Nowadays, we can see yards in Asia installing the following “sub control systems”:
• Level Control Systems
• Valve Control Systems
• Pump Control Systems
• Galley Alarm Systems
• Ballast Control Systems
• Cold Stores alarm Systems
• Fuel Transfer Control Systems
• SW Temperature Control Systems
• FW Temperature Control Systems
• Pump Stby Control Systems (one per pump!)
• Valves (one per valve)

Each of these systems delivered from different companies with their own PLC and local touch screen.

All these systems were connected to the IACS via a serial line.

The yard often think this is a good idea, as all systems come already commissioned, and the yard doesn’t
need to take any responsibility at all.

THE HUGE PROBLEMS WITH THIS DEVELOPMENT

The first problem is to get all these systems to communicate with the IACS in a stable way.
And when communication problems occurs, it will be difficult to identify who is to blame, and who has to
pay for the failure detection job.
But the real nightmare occurs when these vessels leaves China, and start to operate in different parts of the
world. That is to say, when a vessel’s operations depend on all these computer systems, and the right service
engineer has to travel from all the way from China.
Remember that the vessel’s electrician may be useless as the system is controlled from a PLC, and not the
traditional way, from relays.

As long as the company that delivered this system is available, it will be possible to keep it running. But as
soon as one of these companies disappears, the problems start.
When a PLC has to be replaced, the existing logic has to be present, along with the functional specification
for the plant.
If this is missing, getting this small system up and running after the failure of a cheap PLC can develop into
a big job.

As these units are now used within the vessel’s most important components, the operation of a ship now
become totally dependent of a working PLC.

One small PLC with a cost of $100, may today set the most sophisticated vessel out of operation, by
taking out one component needed for DP2 operation
 Page 6

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

A recent example
A 8 years old OSV had a fully redundant installation and DP2 class.
The two main engines were each controlled of a PLC. One of these PLCs failed, resulting in ME failure. No
spare unit was in store. Nor was it possible to get a unit from the manufacturer, as this unit was not under
production anymore. The owner did not have any application SW nor any tool SW, nor a PC for the job.

The vessel faced a minimum of 4 weeks off hire due to this $200 PLC

The story ended well, out of pure luck. A PLC was found in a remote warehouse in Germany. An old
programmer with an old laptop with the appropriate SW was found.
The final luck was that the type of PLC had a function for SW dump! (Which is pretty rare)
The SW from the opposite ME was downloaded and upload into the replaced unit.
Just PURE LUCK saved the owner form a considerable off hire cost.

LACK OF BASIC KNOWLEDGE OF MICROPROCESSOR BASED

TECHNOLOGY
The fundamental difference between a traditional relay logic and a microprocessor is not known to the ship
owners today.
Some ship owners do not have any technical staff which have knowledge and experience with the electric
field on board the vessels.
Traditionally, the ship owner’s technical staff is recruited among marine engineers with a mechanical
background.
There is no tradition to use electrical engineers for leading positions, as the electricians have been used as
“light bulb replacers”.
The consequence of this is that advanced diesel electric vessels have been designed by engineers without
any knowledge what so ever from electrical systems.
The specifications have been copied from similar vessels, with catastrophic consequences.

This is mainly due to lack of understanding of the complex problems introduced, and the serious
consequences that may be introduced.
It is also a common understanding in the industry, that these changes are “modern” and therefore must be
accepted in order to be an “up to date” and modern customer.

Experienced engineers have been forced to accept all new fashion / modern design, due to the lack of
detailed knowledge, and the fact that everybody else is accepting it.
 Page 7

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

THE HUGE DIFFERENCE

The huge difference between a microprocessor and a traditional electronic control circuit, is the
PROGRAM.

Program Example

PLC details
There are a large variety of PLC types, based on many different techniques, but most of them will contain
some kind of memory layout.

Bootstrap Loader area PROM Bootstrap Loader

Contains a small SW for loading of firmware EEPROM /
Firmware
RAM
Firmware area
Contains the operating system, where basic SW and libraries are
EEPROM /
stored. The functions of the SW depends upon the Firmware. RAM
Application SW

Application SW area
Contains the Software for the specific application EEPROM /
Parameters
RAM
Parameters area
Contains changeable parameters for the application SW
 Page 8

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

All microprocessors must have a program to execute, and this program is stored in a separate storage
media.(Application SW)
There are today a lot of different storage medias available to the market:
- RAM
- ROM
- EPROM
- EEPROM
- FLASH
- Hard Drive
- DVD
- etc

Some of these storage media are dependent of a healthy battery backup in order to keep the program.
Some of the media have a limited lifetime, and will have to be replaced several times during the lifetime of a
modern vessel.

There are several problems connected to the CPU Program.

1. The microprocessor will not work at all if the program is lost.
2. There is no limit for the actual number of combinations in a program!
3. There is a huge risk that the program contains one or several BUGs.
4. There might not be possible to recreate a BUG after an event.
5. Critical Parameters may be lost or set back to default after a “Cold Start”

These problems are the reason why programmable solutions require a totally different way of handling from
the supplier to the yard, and finally to the owner.
 Page 9

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

ENGINE ROOM VITAL COMPONENTS THAT MAY BE CPU CONTROLLED.

CPU controls have now become common in a number of vital systems onboard a vessel.

It is very important for the owner to be able to identify these components.

The reason for this is that a CPU controlled device is totally different from an analog device or a non
programmable device.

- Diesel Engine control systems

- Shut Down systems
- Governors
- Voltage Regulators (AVR)
- Power/Frequency/Current Converters
- Synchronizers
- Generator Breakers and Consumer Breakers
- Load Control / Blackout prevention systems
- Breaker interlocking systems
- Power Management Systems
- Fuel control systems
- Cooling control systems
- Propulsion Drive systems

- This is a module used for hydraulic valve control with variable opening.
- This unit contains a CPU, and has a number of parameters that need to be set in
order for the unit to operate correctly.
- These units play an important role in a million dollar crane installation, and
may cause a million dollar damage.

If a unit like this is replaced without a parameter update, the system may work, but crucial safety
functions may be missing. Or it might cause a total change of the function.
It might cause a 400 ton crane to fail in a critical lifting operation, and cause huge damages

It is not common knowledge, but it is a fact that CPU systems have got a number of abilities which may
cause the system to act faulty, and cause failures in the vital components.
 Page 10

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

PARAMETERS, A CRITICAL VARIABLE

General
Most CPU systems operate with parameters.

A Parameter is normally a number describing constant values, or initial

values in the SW.
In a modern vessel the number of parameters easily increase to 50 000!
A faulty value of only one of these parameters may set the vessel out of
operation.

A parameter may be used by the system supplier to alter the behavior of

the SW from a standard version to the actual installation on the vessel.

These parameters may be:

- Nominal Frequency
- Nominal Voltage
- Normal power
- Max Current
- Start Delay time
- Shut Down Level
- Etc

Some systems come with all parameters set from the factory, but often adjusted during commissioning.
Some suppliers always alter these parameters during start-up.
The parameters may be stored in different ways, dependant of the actual CPU system.

Parameters stored in RAM

When the parameters are stored in RAM, it always comes with a battery installed to enable the RAM to keep
the parameters.
When the system is powered by a UPS, the battery is not in use, as the RAM is powered from the main
power.
This battery is only needed in case of a UPS failure.
If this battery is not replaced at regular intervals, it may be empty when a UPS failure occurs and the
parameters will be lost. Some vessels may also never encounter a UPS failure, and will never notice the
faulty battery. But if the vessel has a blackout for more than 30 minutes the UPS will eventually go down,
and the CPU system with the faulty battery will lose power.
When the power is restored, the parameters are erased, and the system will start up with default parameters.
In some cases, those are possible to run with, and the vessel will be operating with a vital system running
with default values, without any of the adjustments from the commissioning active. This is a critical failure
often experienced by this type of CPU systems.

Parameters stored in EEPROM

E2 prom parameters are safer than the RAM parameters, but may also be erased by the system.
Typically when a new SW version is loaded, many systems will reset the parameters to default values, as the
parameter set no longer will be compatible with the new variable structure in the new SW.
 Page 11

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

Parameter change
In some CPU systems, the supplier has pre-loaded a large range of programs, for a set of products
controlled by this general CPU module.
It might be that one parameter will control if the unit should act as a generator or as a motor.
When the parameter is set to “m” the motor program will be activated, which is totally different from the
generator program.

One small parameter may actually change which part of the program is active. None of the tests performed
during commissioning and sea trials will have any value any more, as the unit is using a different program.

It is therefore essential to keep a parameter list, where all parameters are logged and changes are
documented.
Where a laptop is used to read and write parameters, a parameter file will probably be available.
This file should be stored, and marked with revision, and revision comments.
Also some kind of parameter comparison tool should be available, to check new SW revisions for possible
parameter deviations.

Parameter verification after system update

Many systems will lose the parameters when the SW or Firmware are updated to a newer version.
The reason for this, is that the new SW will not always use the same parameters as some may be deleted and
new ones will be added. Or in some odd cases the parameter will get a different meaning, or range etc.
In these cases the parameters have to be configured once more, and a new test would sometimes be
necessary if some tuning is required.

Lack of parameter version handling

As a parameter may alter the way a device will work, it is not just a simple and unimportant value, as
defined by the classification societies and some owners.
All parameters of important equipment are crucial for the vessel’s operation, and require a lot more attention
than what they get today.
Ship owners today have almost no focus on the parameters, as they do not understand the consequences of
parameter changes.

The focus on parameters should be increased, given the possible causes of a change.

One single parameter change, may totally alter the logic in a crucial software of the vessel.
 Page 12

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

Parameter storage and verification

The parameters are normally set via a PC or a special tool, and kept by the supplier.
Sometimes the parameters are delivered to the owner after the sea trial, often printed on a paper, or on a file.
But in most cases the parameters are simply left in the system, and the responsibility given to the owner.
Even in cases where the parameters are handed over to the crew, there is no system today to keep track of
them, as there is too much data to handle for a printed list.

It is currently almost impossible to verify that all parameters are correct, or according to the design after sea
trial.

Today, there has not been much focus on these problems, as few are aware of the critical role the parameters
play.

COMPUTER SYSTEM UPGRADE

As each of these different PLC’s contains a PLC program, and all brands have different format for the logic
inside, it is not possible to replace a PLC with one from a different brand.

So, when one unit is to be upgraded, it must be done with the same brand, but also with the same model and
firmware version.

In order to upgrade a PLC, you will also need to process the SW, and the tool for uploading the logic.

But the big problem comes, when you are not able to get a spare PLC of the same model.
This is because the models are rapidly changing and replaced, and the older ones become hard to find.

As a newer model may use a different format, the logic from the old PLC, may not be compatible with the
new model, and therefore impossible lo load.

In cases like this the total SW may have to be made from scratch, a job that may take a long time, and
involve extensive testing, and even new classification tests.

This is not the only problem, as the new PLC might not be compatible with any other system it was
communicating with, which may lead to an upgrade of other systems on the vessel as well.

In the worst cases, an upgrade of a small PLC, in a sub system, may lead to a necessary upgrade of the
complete control system on the vessel.
 Page 13

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

FAULT TRACING AND LOGIC UNDERSTANDING

When a problem occurs onboard, it is essential that the problem can be identified quickly.
When the logic was made by relays, any electrician or engineer would be able to fault trace this control
circuit.

The same function controlled by a PLC

When the same function is controlled by a PLC, a total different approach has to be put in place.

Without the PLC logic program it is impossible to fault trace this motor control.
There is no guaranty that this unit will operate according to the specification, as the logic is not present.

In order to debug this unit, the engineer has to be skilled in this type of PLC units, and needs to have the
necessary tools together with the correct uploaded SW version.
 Page 14

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

SOFTWARE TESTING
General

Traditionally, a system would be trusted, after it has been tested thoroughly.

This is unfortunately not the case with a computer based system, which contains timers and combinatory
logic.

A CPU with only some inputs and some program timers can contain more possible combinations than the
total number of atoms in the known universe!
This means that it is not possible to fully test a CPU controlled system, the same way as analog systems
were tested in the old days.
With only one timer running in the system, it is possible for the system to act differently for every tick of
this timer.
So, if a function was tested and found working, it may not work the next second, minute, day, month or
year, depending on the timer’s speed and the influence of this timer in the SW code.
Or, if just one of the signals in the system has a different value, the result may be completely different.

Many ship owners believe that, after an extensive testing during HAT and SAT, and even with HIL all
problems have been detected and that the systems will operate without major bugs after delivery.

But that is not the case!

Thousands of bugs may still be present in the system!

They are just hidden, and will only appear at odd situations, and at random times.

HIL Testing

HIL – Hardware In the Loop Testing has been introduced in recent years by third party companies.
The test is performed by connecting a simulator to the control system, and letting the system run, while the
simulator detects the actions and any fault action taken by the control system.

For systems with complicated logic sequences and mathematical algorithms, this is an effective way to test
parts of the system.

Most of the serious suppliers today run the critical code in their own HIL facility, in order to detect the most
obvious failures.

The problem, however, is that there are just a small number of faults in the system that can be
detected with a HIL test!

As the number of combinations in such systems are practically infinite, there may only be a certain amount
of combinations that would cause the system to fail.
 Page 15

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

Number of combinations in a simple logic

Why is the number of combinations this enormous?
A program normally uses hundreds, or even thousands of variables and programing lines with code.
Each one of these variables may be set to different values, depending on the variable type.

If a timer is involved and declared as a data type DWord, it may have 32 bit value (4bytes)

10110011100010101111001010110010

This DWord value, is a binary number with 2 32 combinations which is 4 294 967 296.
So a normal timer may result in more than 4 billion different cases in the SW to be checked!

When only one single timer is involved in the logic, the test must be done with all combinations of this
timer.
If the timer value is increased every second, the same value will occur every 136th year.
This means that if this timer is included in a faulty SW logic, the fault may only occur once in the lifetime of
the system, or once some years after the system has been restarted.

To be able to do a test of this system and detect the failure, the system needs to test all combinations
every second in a period of at least 136 years! IMPOSSIBLE

So, with only one single value involved, this will result in so many combinations, that it will not be possible
to test all values.
If you add another 32 bit timer to the system, the number of combinations will increase to 2 64
combinations!
For a system with only 100 AI channels of each 16 bit resolution, the number of combinations will be:
2 (resolution in bit * number of variables) = 2 16 * 100 = 2 1600 or 10 480 combinations !
As a comparison, the total number of atoms in the known universe is assumed to be 10 82

Example 1 - SW bugs which cannot be detected by any test

On board a vessel there is a PLC controlling the short time paralleling and interlocks in the main
switchboard.
This PLC is also sending a trip signal to the tie breaker in certain situations.
The program controlling this output is pretty complex as there are a number of criteria for the trip to be
activated.
The logic also contains a number of timers.

Inside the logic there is a crucial bug, which will cause the generator breakers to disconnect when a 16 bit
timer reaches the value 0, and DG3 is connected to the MSB, with LOAD < 5% (Which sets the LOADED
flag in the system)
The 16 bit timer is using a WORD as the variable, which only have 16 bits binary value, which gives 2 16 =
65535 different combinations.

The timer starts to count from zero when you reset the system.
The value is increased with 1 for every second.
 Page 16

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

In the SW, the programmer have inserted the value for DG3 LOADED instead of the variable
TIE_NOLOAD.
This programing mistake will cause the tie breaker to trip when this timer reaches the FFFF H value, or the
decimal value of 65535, together with the variable DG3_LOADED is not set.

The timer will reach this value after 65535 seconds which is approx. 18 hours and 12 minutes. A word
value, will start from zero after reaching the maximum value FFFF.
This means that this failure only will occur if DG 3 is connected with low load, when this timer reaches
FFFF.
It might take years until this combination occurs, and almost impossible to re-create, as the timer only kick
in every 18th hour.

If the timer have been a 32 bit timer, the same combination would have occurred once every 128 year!

Example 2 - SW bugs which cannot be detected by any test

This example is constructed and not likely to be a real case, but it indicates the problems on how to detect all
failures by testing.

In this example there are only two simple comparator elements, reading two integer values each.
The first comparator will give a logical True on the output O6 when the Sea Water temperature have the
same value as the Ships Speed.
The other comparator gives a logical True on the O6 when the time of day is 0, ie the first hour of the day.
The Trigg element converts the positive edge of the output to a single Pulse.
The output of the AND gate will initiate a total shut down of all generators if the Ship Speed equals the
Engine Room Temp in the first second of the day.

This logic may never be activated, but it might happen.

Example 3
One example from testing of a Power Management System on a large drill ship may describe the problem
with SW bugs, and how difficult it is to detect.

During testing of the system, all was working well.

Some days after delivery from the yard, strange things were detected. A Generator was suddenly started by
the PMS, for no obvious reason. It was not possible to recreate the problem, and the vessel just continued
into operation.
Some months later, the same thing happened.

The problem was detected several times, but with no obvious reason.
 Page 17

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

After further investigation, the crew was able to see that the problems started during fuel transfer.

With this clue, the SW engineers were able to detect a wrong SW connection in the PMS.
The signal for the “DO Transfer pump no 2” was connected where the signal for the “NR3 Heavy Consumer
start request” should have been.
This signal had a tag name like this “651_002_051_XC”

The power request no 1 and 2 had similar tag numbers, “851_002_051_XC”

When looking in the SW, it was not easy to discover this programming error, especially since this actual 3rd
heavy request was not in use for this system, but it was in the PMS as a standard feature.
This is why it was not possible to detect any failure during PMS testing, as this actual pump was not
running.
Impossible to find.

How to find “hidden” bugs

This type of programming errors are unfortunately not just a theoretical case, but exist in many systems
running to day.
When a bug like this causes a blackout on board an offshore vessel, the consequences may be catastrophic,
and an explanation has to be found.

The crew will then try to create a similar situation in order to cause the bug to occur again, but without the
knowledge of the special SW connections, it is not possible to recreate.
The crew will desperately hunt for the cause of the blackout, but: WILL NEWER FIND IT !

But as the client demands an explanation, something needs to be found.

So, the report concludes with the finding of a loose wire or the replacing of a component that could be the
cause, just to be able to close the case.

This type of logic failures in the control system will never be detected in any system test nor in a HIL
test !

Code Reading
One way to increase the SW quality is by code reading.
This method has been used in industries where the consequences of a SW bug have a large economic
impact.
Typically, in aviation and aerospace industry, it is mandatory to do code check of all critical SW in the
systems.
This is often arranged with three individual programmers, not working in a team, but often separately.
One programmer would write the code, and the two others would read the code and check for bugs.
Then they would rotate the responsibilities, as all three would take part in the actual programming job, as
well as the code reading.
 Page 18

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

Programming languages
One of the large problem in the industry is the wide variety of programming languages. Several hundred
standards are in use today.

Some of these languages are low level, as they are

working close to the Microprocessor instructions.
The most known is Assembly, which was a
common language in most smaller systems 10-20
years ago.

This language is used when the programmer needs

to make a fast code, with the minimum of
overhead, and the minimum use of memory
(RAM)

It is however rarely used today, as the speed of

microprocessors has dramatically increased over
the past years, together with an increased RAM
area available.
This language is difficult to write without bugs, and very difficult to maintain and expand.
Doing a code reading of this language is a very time consuming and expensive task.

High Level Languages

There are also higher level languages, like C, Pascal, Fortran, Basic, Java etc.
These languages have the ability to be presented in a way that is very easy to read and to maintain, but
unfortunately this is up to the programmer.
If the programmer is not focused on writing a structured code, it might be impossible to read, and may
contain hidden bugs.

The following line is written in C

m_gen ? ok=true : m_gen==1 ? ok=newClusters(Sp) : ok=newSeed(Sp);

This line is very difficult to read unless you have long experience and are a trained programmer.
The equivalent for this is:
if (m_gen == 0)
{
ok = true;
}
else if (m_gen == 1)
{
ok = newClusters(Sp);
}
else
{
ok = newSeed(Sp);
}
This is easier to read, but still not easy for a non programmer.

Anyway, reading this language in order to find bugs, is still a complicated task, even for a trained SW
 Page 19

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------
expert.

Program block
The following programming lines are the program code for the logic of sending the start signal to a
generator engine in a drill ship.

.1:5 = COMP-R(ME2_RPM,IGN_RPM);
.2:20 := SR(AND(ME2_M_START,Not ME2_START_BL,
ME2_MANUAL),OR(ME2_START_FAIL,ME2_LOCAL,ME2_RUNN_C,0,ME2_SD_ALARM,ME2_PRW_ALARM,.1;5));
.8:20 := SR(AND(ME2_A_START,Not ME2_START_BL,
ME2_AUTO),OR(ME2_START_FAIL,ME2_LOCAL,ME2_RUNN_C,ME2_M_STOP,ME2_SD_ALARM,ME2_PRW_ALAR
M,.1;5));
ME2_STARTING := OR(.2:20,.8:20);

When looking at this, it is almost impossible to read.

The solution is the programming language Function Block Diagram (FBD), a part of the 61131 IEC standard
in use in modern PLC’s.

One of the major problems, is that the SW expert has normally no experience with marine applications, and
probably no sailing time onboard any vessel either.
The necessary knowledge to understand the way a generator should behave is normally missing for a person
with detailed SW understanding.

But with FCB programing any engineer will be able to debug and understand this code when logical names
are used, and the SW is structured in a good way.

In case of programming applications that should be controlled by a non SW skilled person, this code is the
only alternative, and should always be mandatory.
 Page 20

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

Conclusion SW Bugs
• There is no way to test the SW for all kind of bugs.
• Not even a HIL test will detect special programming bugs.
• Some bugs may be hidden in the system for months or even years before they appear, and even then
might do so only once in the lifetime of the vessel.
• The actual programming language used by the supplier is important for the ability to read the code.
• FBD should be used in important logic where code reading is necessary.
• SW generation tools have to be utilized, to prevent manual punching mistakes.
• Qualified programmers with a suitable quality system are required.
• An independent code check of all important programs is required.
• Simulator and HIL tools* must be used.

* Suppliers normally have the ability to connect the system to an own HIL simulator, which should be
required during FAT, as the third party service sometimes are too expensive compared to the benefit of
the service.

EXPERIENCE FROM THE OIL INDUSTRY

When the oil installations grew larger in the
seventies, the oil companies, experienced that all
suppliers had to install their own operator interface.
Each supplier delivered an operator interface to be
installed in the control room.
This lead to a huge number of operator interface
panels in the control room.
In addition to this, each supplier started to use its
own computer control systems, which required
dedicated programming and maintenance tools.
In the end, the maintenance of all these computer
systems grew extremely expensive, and upgrading
them was almost impossible.

The oil industry, which has more economic and technical resources with detailed computer knowledge, has
identified this problem decades ago.
This industry has taken steps to avoid many of the consequences in the change of the basic design technique
for control systems.
But specifications developed to gain the highest operation availability in critical installations, have
unfortunately a substantial cost impact for the installed systems, and are therefore not considered in the
marine industry.
 Page 21

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

NECESSARY ACTIONS FROM THE OWNER SIDE

General
In the coming years this problem will erupt all over the marine industry, and add substantial maintenance
costs to the vessel operation budgets, as well as increasing penalties due to downtime.

Can the classification societies help?

Many ship owners relay on the classification societies to set the necessary requirements to the industry.
Unfortunately these companies do not have the necessary product and system knowledge to set the
necessary requirements. Another problem is the fact that these companies actually are competing with each
other, which results in rules that do not set “expensive” requirements.
Such companies often make rules based on events reported from the industry, and this makes the process
very slow.

The only solution is that the ship owners start to take a stand, and make specifications and requirements that
will ensure reliable and durable systems, that can be operated and maintained in a safe manner, with respect
to SW and parameters.

The solution will raise the cost

But the big problem with setting a new standard, is that it will increase the investment cost, where the saving
is hard to calculate, due to the fact that the calculation is stochastic *, in order to estimate the probability of
an critical incident in within life time of the vessel.

* Stochastic calculations: used to calculate the risk of an accident with many variables

There are ways to improve the availability, to minimize the consequences of a failure, and the to limit the
system downtime.

There is almost impossible to make a microprocessor-controlled control system 100% safe !

In the end the system will have to be SIL classified in order to increase the availability towards 100%, but
this adds a considerable cost to the systems.

Actions
All ship owners should be aware of the consequences of using microprocessor based control systems, and
how to take the necessary steps in order to increase the SW quality, as well as the risk of maintenance issues
during the life time of the vessel.

For new building, the ship owner should state special concern for the installation of any PLC that are not
part of the IACS.
 Page 22

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------
Today it will be impossible to have all systems integrated in the IACS, as a lot of suppliers have the power
to refuse to take out the PLC.

In such cases there should still be some basic requirements before the PLC is accepted.
1. Require the installed SW to be supplied with the vessel
2. Require the SW logic to be shown for a third party check
3. Require the necessary programming tools to be supplied
4. Require a SW revision log to be supplied along with the system.
5. Require skilled SW engineers to do the modifications with an indicated reason.
6. Require information on the parameters and the changes done. (Parameter DB-LOG)
7. Require information of any battery installed, and the maintenance intervals

Revision Handling
It is extremely important that the SW version is identified, and that any spare unit has the latest SW version
installed.
It is also important to have a log onboard, listing the different SW versions installed during service, together
with the information on the nature of the modification.

It should be mandatory to log all SW modifications, for ALL programmable devices onboard!

The number of subsystems is increasing rapidly and increases the need for basic rules.

Program Revisions
Due to the fact that computer Programs change and need modification for different installations, and
upgrades due to bugs, all these Programs should have a version number.
Today, there are no yard/owner requirement for suppliers to keep them updated on these SW versions, nor
any owner requirement to report the discovered bugs and the remedies performed to cope with them.
In the requirement from the classification societies, there are a number of rules for the way of handling the
SW revisions, but none of them are currently required from the yard or the owners.
This leads to a total lack of any system keeping track of the SW versions on board a vessel.

Require parameter and SW lock

As changing only one parameter may alter the program in a CPU, it is vital that parameter change and SW
uploading are restricted.
It is crucial that no parameters are changed or no SW is altered without an approval process.
This approval process should contain:

1. The reason for change

2. Implementation time date and revision update.
3. Change approved by an experienced system engineer
4. Change approved by the chief engineer.
5. Change performed by an experienced engineer.
 Page 23

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------
Parameter database
There should be a parameter database on board, which also is copied to the shore office.
This database should contain all parameters on board, from all critical systems.
There must be a strict policy for all suppliers to keep this DB updated.

In the future this database should be online, in order to also detect parameters being changed due to a battery
backup fault, a mistyping, or a faulty copy from another vessel.

Logging

Without signal logging, it is almost impossible to find the cause of an event after incidents caused by a
PLC.

The control system installed should have the ability to log all signals in the system with at least one sample
per second.
In addition Events should be generated for all Digital inputs and Digital output signals, with a minimum of
500 ms resolution.

If the control system is also equipped with a “playback” (GMR100 @HMA trademark) facility, the crew
will be much better equipped to track down any SW bugs in the IACS, or in any of the subsystems which
will probably be connected.

GUDELINES FOR THE VESSEL BUILDING

General
After several installations with these problems, some larger oil companies introduced a total limitation of
operator interfaces in the control room.
• All systems should be interfaced through the one selected system supplier selected for the total
installation.
• All computer control systems used in any installation on board have to come from the same brand
(such as SIEMENS, ABB, OMRON, etc)
• All programs used in the system should be delivered to the owner
• Protocols to sub systems should be limited to Modbus, NMEA and Profibus
• Suppliers with proprietary HW should be avoided.
(The used HW should be available from the shelf from independent suppliers)

This requirements limited the total use of one control system on board the installations.

This new requirement also introduced additional costs, as a lot of suppliers of complicated mechanical
packages already have standardized in using a different type of PLC's. All these suppliers, were then forced
to remove this PLC from the package before delivery. Some of these control systems were pretty
complicated, and the new program made in the standard PLC had to be made once more in a different
programming language.
 Page 24

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

The definition of "Interface" compared to “Integrated”

Today, some ship owners uses the following wording in the specification:
"all sub systems must be “interfaced” to the IACS"
This will normally allow the yard to install any type of system, regardless of the brand and type, as long as it
has a communication interface.

Another sentence is this:

"all sub systems must be “integrated” into the IACS"
This is more correct, but some yards would define integration, as a communication line where the values are
presented on the IACS VDU.
It should therefore be specified that by the word INTEGRATION, it means:

All “sub units” or “sub systems” is to be controlled by dedicated I/O signals, and all logic is to
be implemented in the IACS. No local logic will be accepted without approval.

This requirement will only limit the yard to deliver one type of operator interface, but will still open for the
use of any type of control computers in the sub systems.

When an “interface” is supplied, a communication protocol will be used to exchange data.

Introduction of a communication protocol generates a number of problems:

• Limited amount of data will be present at the superior system
• Second VDU is required for parameter adjustment and debugging.
• Time consuming commissioning, and debugging phase
• Impossible to test all combinations, and problems may occur after delivery
• Difficult responsibility definitions, which results in increased service cost
• Requires engineers from two companies present when debugging protocol.
• Different programming language, different service engineer etc.

For a ship owner it will also be difficult to require all suppliers to remove the standard PLC, as a lot of them
have chosen one for the package supplied.

On the other hand, if no requirements are made, the use of cheap PLC's will grow into all kind of equipment
on board, and the owner will be left with a huge number of problems during the life time of the vessel.

Programming tools
If the delivered PLC requires a special programming tool, or cable, this should be supplied together with the
spare parts. The tool is probably also made for a certain operating system like
DOS, Widows3.11 / 95/ 98 /NT/2000/XP/7 Linus, Unix CPM, etc.
The problem, is that these programs do not run on newer versions of the operating system!
Some programming tools, still requires a PC running MS-DOS!
And then the PC must also in some cases be old enough, as newer PC’s will be too fast for the SW.
Nowadays, PC manufacturers do not make HW that is backwards compatible, that means that it may be
difficult to purchase a suitable PC for an older Windows version.
This means that all different systems requiring a SW upload or SW parameter tool, would require one PC
dedicated solely to this use.
 Page 25

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------
APPENDIX

Suggestions for wording in a ship specification:

Computer Systems for machinery control
• One control system to be selected for controlling all systems Engine Room systems on the vessel.
(Main Supplier)
• No control system to be delivered with a package, unless it is the same brand as the Main Supplier.
• Any deviations from this, to be approved by the owner case by case.

The yard will be responsible for limiting the number of PLC's on board the vessel.
Only large installations may have a PLC installed, such as:

• Diesel Engines
• Thrusters
• Drives
• or components with a certain number of alarm points > 200
• No COMMON alarm should be accepted, as this introduces problems with multiple alarms

All PLC's installed should be of the same brand, as selected for the Integrated Alarm System.

No PLC's from a different brand should be supplied in any package without the approval of the
owner.

If a different PLC is supplied, several details have to be supplied with the unit.
(Unit list)

List of Installed Systems

When the vessel is delivered to the owner, the yard shall deliver a list of all microprocessor systems
installed on board the vessels.
This list has to identify the following:
- Supplier, contact details
- PLC brand , type number
- SW version
- delivered spare units (if any)
- installed SW version in the spare unit (if any)
- Unit is containing Batteries
- Battery type, and replacement interval
- Fan type, ordering details, if installed.
- Programming tool supplied
- Backup of the installed program (version) supplied?
- List of all parameters for all systems delivered in a common Database
- SW code listing (file, PDF or source code)
- FDS of the functions in the delivered system
 Page 26

The consequences of the new microprocessor controlled vessel

By Kåre Høglund – Høglund Marine Automasjon A/S
-------------------------------------------------------------------------------------------------------

This document have been issued in order to inform the ship owners of the consequences of the
microprocessor revolution in the marine industry.
We do not claim to have the solution to this problem, as the price consequences for implementing the ideal
solution is enormous.
But by following some simple steps, the it is possible to get a better view of the installed systems, and the
maintenance of the systems in the future.

Rev Chapt Description Issued Date

. .
0 Issued for information Kåre Høglund 15-11-2013