Administrative System Vedlikehold Diagnose

1
Administrative SystemVedlikeholdDiagnose
2
The FleetMaster Concept

• A gateway to the Control and Navigation system.
• The system gives access to data at a higher
  level, for administrative use.
• The FleetMaster Concept consists of applications
  for use onboard and for use onshore.
• The user onboard will get online information
  which they need in their daily operation of the
  ship.
• The ship operator/owner needs more global data in
  order to support, organise and operate the ship
  fleet.

3
Information Management

• Onboard ShipIntegration onboard between the C20
  Process Administrative Networks
• Provides access to the C20 Automation and
  Navigation Data.
• Organises and stores data Onboard.
• Presentation Decision Supporting.
• Automatic Manual Ship Reporting

4
At Ship owners officeIntegration of the Ship
Fleet the Ship Owner office

• Provides access to the ship networks
• Organises and stores data.
• Presentation Decision Supporting.

5
FLEETMASTER
6
SHIP GATEWAY

• Access to online information from the DataChief
  and BridgeLine systems
• Recording of data into files
• Recording of data directly into databases
• Special calculations and normalisation of values
• Provide information to third party systems as
• planned maintenance system,
• loading computers,
• fire alarm system,
• hull stress monitoring,
• MIP calculators etc

7
SHIP EVENT RECORDER

• The ship event recorder is a database where all
  alarms from the DataChief is recorded and stored.
  
• The database also contains statistic tools for
  analysing the alarms.
• Recording all alarms which is triggered in the
  DataChief.
• Statistic treatment of alarms
• Detecting of alarms which occurs to often
• Documentation of testing of alarms
• Detecting of alarms which needs to be tested
• Diagnostics of instrument failure.

8
SHIP DATA MANAGER

• The Data Manager consists of a database
  containing all required reports for
  communicating between ship and shore.
• Voyage Report
• Engine performance report
• Loading/Discharge report
• Auxiliary engine performance report
• Hull Propeller Report
• Engine Room Log Book
• Automatic transfer of data to ship
  owner/operators office
• Automatic reporting to class societies

9
APPLICATIONS ONSHORE
10
Typical Data collected and use

• Reports from the Ship Data Manager
• Snap-Shots from alarm monitoring and control
  system. Used by superintendents to se the status
  onboard.
• Data Collection from the ships MIP Calculator.
• Data from Planned Maintenance System.
• Data from Vibration monitoring system.
• Other documents from ships.

11
FLEET DATA MANAGER
12
Fleet Data Manager

• The Fleet Data Manager provides storing,
  organising of data from the ship fleet, so that
  trending and comparing of ships are relatively
  simple.
•  Collecting / Receiving information from the ship
  fleet
• Organising Storing
• Pre-defined reports
• Trending of data
• Analysis of ship fleet performance

13
MIP CalculatorMean Indicated Pressure
14
Autronica MIP

• Gi oversikt over motorfeil som fører til økt
  spesifikt brennoljeforbruk.
• Holde kontroll over motorens termiske
  belastningsniva.
• Holde kontroll over motorens mekaniske
  belastningsnivå.
• Analyserer
• Forbrenningsprosessen.
• Luft/eksossystemet.
• Brennoljeforbruket
• Sammenligner med referansedate. (Prøvetur)

15
CoCoS - Computer Controlled Surveillance  
16
CoCoS software

• The objectives of the CoCoS software products are
  to provide
• Increased availability and reliability of diesel
  engines
• Efficient reduction of operating costs and losses
• Efficient planning of engine maintenance
• Easy and unambiguous identification of spare
  parts
• Integrated stock handling and spare part ordering

17
EDS - Engine Diagnostics System
  
18
The main objectives of CoCoS-EDS are

• To assist in decision making on board, at the
  power plant, or at the office 
• To improve availability and reliability of diesel
  engines
• To reduce operating costs and losses that result
  from engine failure

19

• It automatically provides on-line CoCoS-EDS with
  sampled data on the states and behaviour of the
  diesel engines monitored
• Data Logging is the primary information source
  for CoCoS-EDS.

20

• Manual input and measurements are the secondary
  information sources for CoCoS-EDS. These features
  enable the use of CoCoS-EDS with equipment that
  is not physically connected to it

21
Monitoring
22
Diagnostics

• The diagnostic process generates and displays
  diagnoses at an early stage, thus enabling timely
  detection of irregularities.
• With these diagnoses, you can take precautions to
  keep the engines in optimum condition.
• The diagnoses are based on symptoms of unusual
  states or behaviour of the engines, including
  faulty sensors, wear, dirty filters, etc., found
  during the evaluation.
• Diagnostics explain what is wrong, the symptom(s)
  that led to this conclusion, and what measures
  should be taken to normalise the state of the
  engine

23
MPS - Maintenance Planning System
24

• Automatic Job Requests
• It automatically issues requests for periodic
  maintenance jobs, giving them due dates on the
  basis of their recommended service interval and
  their latest service date or latest service
  run-hour
• Manual Job Requests
• The second, equally important method for
  requesting maintenance jobs. It enables the
  planner to issue requests for ad hoc jobs to be
  included in the maintenance plan
• Automatic Requirement Forecasts
• The basis for the budgeting of maintenance costs
  and for the timely procurement of spare parts.
• CoCoS-MPS automatically generates and maintains
  lists stating the dates and number of work hours
  and specifies the individual spare parts, tools,
  etc

25
JOB Definition
26

• Job Scheduling
• The planner's tool for making the maintenance
  plan operational.
• It allows the plan to be fine tuned for the
  availability of spare parts and personnel, and
  for harbour stops or docking periods etc, when
  required.
• The job scheduling locks the job and its spare
  parts, tools and personnel requirements in
  calendar time.
• Job Order Issuing
• The planner's tool for initiating the execution
  of maintenance jobs.
• Issuing of a job order releases the job, thus
  "freezing" its resource allocations and start
  date, and prints its work papers

27
(No Transcript)
28
SPC - Spare Part Catalogue
29

• Multilevel Part Lists
• Each entry in a CoCoS-SPC spare part catalogue
  identifies a specific component - i.e. assembly,
  subassembly or part - defined by a component
  number. The components are organised
  hierarchically in a multilevel part list
  structure
• Spare Part Information
• Each component number refers to a description
  that contains the component's designation, your
  own and the manufacturer's component reference.
• In addition, the component description can
  contain information about the component's
  physical dimensions and weight
• Extended Search
• This powerful facility assists you in spare part
  identification, or when locating their positions.

30

• CoCoS-SPC allows the components to be linked to
  graphics.
• These provide component drawings, assembly
  drawings and exploded views of your equipment and
  components hereof.

31
SPO - Stock handling and spare Part Ordering

• To assist in the handling of the spare part stock
  
• To give up-to-date information on current stock
• To forecast spare part availability
• To assist in the procurement of spare parts

32
Stock Administration
33

• Stock Administration
• When you receive a delivery of spare parts, you
  specify which quantities of which components you
  have put in which location.
• When you issue spare parts for a maintenance job,
  you specify which quantities of which components
  you have taken from which location
• Automatic Generation of Ordering Proposals
• CoCoS-SPO automatically generates proposals for
  spare part ordering, whenever requirements cannot
  be fulfilled at their specified dates.
• The CoCoS-SPO ordering module makes it easy for
  you to make enquiries to suppliers, and to
  prepare and follow-up on procurement orders

34
Ordering Proposal
35
(No Transcript)
36
Diagnosis Functions

• The term fault is used to denote a situation
  where it is possible to draw a conclusion about a
  developing degradation.
• The purpose of the diagnosis system is to detect
  such faults early, assisting the Operator in
  taking actions to perform maintenance and avoid
  failure and damage.

37
Top-level diagnosis system

• Standard Interface
• Data from MAN BW and Wärtsilä Diesel diagnosis
  systems.
• Ship management system
• Process alarm, monitoring and control system.
• Satellite communication system.

38
Condition data is presented in the form of

• Prewarnings
• Diagnoses
• Explanations
• Operator Advises
• Trend Curves
• Trend Predictions

39
System Overview

40
System Modules
41
Modules

•  Database Module
• The internal database contains current
  configuration data, current measurement values,
  prewarnings and diagnoses along with other
  necessary lookup tables
•  Expert System Module
• The Expert System Module represents the Top Level
  Diagnosis, the Auxiliary Systems Diagnoses.
•  Condition Analysis Module (Diagnosis Module)
• The Diagnosis Module represents the Condition
  Analysis functions.
•  Logger Module
• The Logger Module contains functions to log
  historical data, e.g. measurements, calculated
  parameters, prewarnings and diagnoses to hard
  disk.

42
HIPDS in use - scenario example

• Under normal operation, the HIPDS runs
  continuously collecting information from the
  Alarm, Monitoring and Control System (AMCS),
  CoCoS-EDS and FAKS.
• When a parameter exceeds a predefined limit, a
  prewarning is displayed.
• When sufficient information is available, a
  diagnosis is presented.
• Both prewarnings and diagnoses will activate
  attention messages. If the prewarning is defined
  as critical, a message is sent to the AMCS.

43
HIPDS in use - scenario example

• The Operator shall be able to select one
  diagnosis at a time, and further ask for the
  following information
• Diagnosis Explanation
• Operator Advice
• Explanations are available for all diagnosis
  generated in HIPDS. Advises will be available
  for a selected set of diagnoses

44
Working Modes

• For proper Condition Monitoring of the Ship
  Propulsion Auxiliary Equipment, the Ship Working
  Modes are imperative
• In port
• Starting up / manoeuvring
• Normal operation
• Slowing down
• Astern

45
Condition Analysis Methods 1

• Performance analysis
• Calculation of derived parameters, such as
  efficiencies, volume and mass flows etc.
• Identification of actual operating point, e.g.
  for pumps and compressors.
• Calculation of heat transfer coefficients for
  heat exchangers

46
Condition Analysis Methods 2

• Temperature measurements
• E.g. lube oil and bearing temperatures
• Pressure measurements
• . E.g. lube oil pressures
• Level measurements
• Functional tests
• Periodical tests to check the functionality
  (relevant for units with hidden faults).
• Examples are standby equipment and safety valves

47
Condition Analysis Methods 3

• Inspection
• Information gained by use of human senses like
  sight, hearing, smell etc.
• Oil analysis
• Methods to measure particles, water content,
  bacteria, contamination, viscosity, etc. in the
  oil
• Vibration analysis
• The method is relevant for monitoring of
  bearings on rotating equipment like large pumps
  and generators.

48
Condition Analysis Methods 4

• History
• Historical data may be knowledge about previous
  abnormal operational conditions and faults.
• This also includes statistical data (running
  hours, event counting, no of starts, start/stop
  frequency, open/close, connect/disconnect etc.)
• Control loop information
• This category comprises parameters such as
  control deviations, variance and control valve
  position

49
(No Transcript)
50
Condition Analysis Functions 1

• Deviation detection
• Prewarnings

51
Condition Analysis Functions 2

• Parameter Trend
• Trend and Prediction

52
Diagnosis Functions 1

• Auxiliary Systems Diagnosis
• The Auxiliary System Diagnosis (ASD) module
  provides diagnoses in case of developing
  failures.
• Predefined Fault Situations
• Each possible fault situation which ASD shall be
  capable of diagnosing must be predefined.
• For each of these possible faults, a diagnosis
  text must be defined.
• There is a one-to-one relation between predefined
  fault and diagnosis texts in the following
  diagnosis is used as the term for a predefined
  fault situation with a related diagnosis text

53
Diagnosis Functions 2

• The sources for the module input is as follows
• Symptoms signalled by the Deviation Detection
  function as illustrated in Figure 4 and Figure 5
  .
• Estimated process parameters from the Calculation
  function.
• Historical parameters previously stored by the
  Storing function.
• Direct process measurements, having passed the
  Input Data Check.
• Manually entered parameters.

54
Symptoms - Diagnosis Relations

• Symptoms of possible faults are detected by the
  Deviation Detection function.
• In the project engineering phase, such possible
  fault situations must be analysed. This knowledge
  must stored in a knowledge base in forms of
  symptom - fault tables.

55
Additional information

• . To confirm or reject a diagnosis hypothesis,
  ASD may ask questions to the Operator, upon which
  the Operator shall provide an answer.
• Typically, these questions will ask for
  observations which may not be easily obtained
  through measurements.