Files
Abstract
The trend in recent years has been to increase the boundary’s in IPMS capabilities making them more and more complicated with more and more Inputs & Outputs (IO) being monitored and controlled. This is all well and good if the system is a really good one, which has been well engineered, well installed, commissioned even better and then maintained to a high level – then the ships staff could be confident that the system is telling them the truth and will do what is asked of it (in regard to Automatic functions) and what they ask of it.
If the system is lacking in any way, then trust will be replaced with mistrust and the IPMS will become an expensive liability.
This paper will explore the boundary’s of an IPMS system and make reasoned recommendations for how a system should in the opinion of the author be designed, built, tested and maintained. This will include discussing the following aspects:
What is the detailed Aim/Purpose of the system – what is the system needed to do, so that we can decide what is essential and what is possibly ‘nice to have’
Inputs and Outputs to be included – more is not necessarily best and how are they to be brought into the system
Equipment Selection – Commercial off the Shelf or Bespoke
Visualisation software – COTS or Bespoke
Control software – how should this be written/created
Building and Testing standards
Installation standards
Commissioning
Through Life Maintenance – the aim is to be able to keep the existing system working though the life of the ship with simple upgrades and exchanges.