Maximo EAM

BDI Overview and Administration Guide 

Tue January 05, 2021 03:56 AM

1. Introduction

2. System Architecture

2.1 Overview

2.2 Architecture Diagram

3. BDI Status Dialog

3.1 Overview

3.1.1 Current Configuration

3.1.2 Alternative Configuration

3.1.3 BDI Action

4. Installation and Configuration

4.1 Pre-requisites

4.2 Installation procedure

4.2.1 Windows 

4.2.2 Linux

4.2.3 Oracle Real Application Clusters (RAC)

4.3 Configuring Multiple BDI Instances

4.3.1 Initial Setup

4.3.2 Modifying the Configuration Files

4.3.3 Modifying the BDI Start Up Files

4.4 BDI Configuration

4.4.1 BDI Initialisation File Parameters

4.4.2 BDI Initialisation File Encryption

5. Appendix

5.1 BDI Status and Problem Codes

5.1.1 BDI Status Codes

5.1.2 BDI Problem Codes

5.2 BDI Cron Tasks and Asynchronous Jobs

5.2.1 BDI Asynchronous Job Processing Cron Task

5.2.2 List of Asynchronous Jobs Created by the BDI

5.3 Configuration Rule Applicability Matrix

5.4 Troubleshooting

5.4.1 Windows

5.4.2 Cache Synchronisation

 Document owner / Primary contact: Lee Cotton (lee.cotton@uk.ibm.com)

1       Introduction

The Build Data Interpreter (BDI) validates operational changes to configuration-managed assets against the reference data and rules that are configured in an associated model and maintenance plan.

It can be run either manually for a specific asset hierarchy using the BDI Status dialog in the Assets (CM) application and it runs periodically in the background on a pre-defined schedule. In addition, specific transactions performed within the system can initiate a background request to the BDI.

 

Overview of main BDI functions:

  • Checks configuration-managed assets, position by position, to ensure that they comply with the configuration rules established in the corresponding model.  
  • Returns an overall status for an Asset, visible in the BDI Status dialog box and details non-compliance by reporting problem codes and associated information.
  • Evaluates the maintenance program defined for an asset and generates work orders from preventive maintenance (PM) records at a pre-defined alert point.

 

Differences between prior versions:

In ACM 7.6 the BDI was completely re-architected in order to improve performance. The BDI no longer runs as one or more crontasks within the Maximo application and now operates as an independent service. While the overall functional operation of the BDI is consistent with prior versions (ACM 7.5.1.1 and below) a number of important technical differences exist.

The System Architecture section of this document gives further details on this new architecture.

 

2       System Architecture

2.1     Overview

The BDI is a multi-threaded Java ™ service which is independent from the main Maximo enterprise application.

It can be installed and configured on the same physical hardware as the Maximo application, the Maximo database server or on a separate dedicated server.

The BDI service communicates and synchronizes itself directly with the Maximo database (via JDBC) and also inserts and updates data in the BDI status related tables within the Maximo database.

The BDI contains a listener (default TCP port 1608) which allows synchronous communication between Maximo and the BDI.

The BDI does not use the Maximo business objects (MBOs) directly to update data within Maximo for performance reasons. As a consequence, if it needs to perform a transaction which requires utilization of the MBOs e.g. generating a work order from a PM, it creates an asynchronous job which is processed independently by a Maximo crontask.

This allows the BDI to return a status result without the need to wait for these asynchronous jobs to be processed.

 

The BDI is can be run as an independent Windows service. However, since it is a 100% Java system, it can also be installed and configured to run on any other JVM-capable operating system.

 

The BDI Service includes the following threads:

·         The daemon thread monitors and controls the active components of the BDI.

·         The monitor thread periodically processes transactions in the queue that is stored in the PLUSAANTRAN table in the Maximo database.

·         The VREX thread is similar to a Maximo crontask that periodically processes the entire fleet of end items assets and (optionally) uninstalled sub-assemblies.

 

 

2.2     Architecture Diagram

The following diagram highlights the main points of interaction between the BDI service, the Maximo application and the Maximo database:

3       BDI Status Dialog

3.1     Overview

The BDI status dialog is accessible in the Assets (CM) application by right clicking a node in the Asset Hierarchy and clicking the option ‘BDI Status’.

It enables the user to view the status of a configuration managed asset and also make a synchronous call to the BDI service to validate the asset and update configuration status.

The BDI status window contains three sub tabs.

 

3.1.1        Current Configuration

The Current Configuration tab displays the current Model and Configuration(s) which are assigned to the Asset.

It gives an overall configuration status for the Asset as well information on when it was last processed.

The tab also contains a table listing the problem codes reported by the BDI service (refer to Appendix – BDI Status and Problem Codes for a full list of these values).

3.1.2        Alternative Configuration

 

The Alternative Configuration tab lists all of the Model configurations which are able to be applied to the current asset.

It gives the user the ability to validate a different configuration by using the “selected” checkbox and Validate Configuration buttons.

The ‘Status for Selected Configuration’ and Problems table displays data relevant to the configuration that was selected and validated.

The user can also apply the selected configuration by clicking the “Apply Configuration” button.

3.1.3        BDI Actions

The BDI Actions tab contains a list of the asynchronous jobs that have been created by the BDI service for the current Asset. Each job has a status and expanding the table row gives additional information about the processing of the job.

The asynchronous job records are stored in the MAXASYNJOB table and are processed by a dedicated series of Maximo crontasks.

Job status values:

  • SUBMIT –  Job was created and is awaiting processing.
  • INPROGRESS – Job is being processed by the corresponding Maximo crontask.
  • COMPLETE – Job is finished processing.
  • ERROR – An error was encountered during processing of the job. Consult the Job messages for further information.

 

4       Installation and configuration

4.1     Pre-requisites

The BDI service requires Oracle Java™ Runtime Environment 6 or a later version.

 

4.2     Installation procedure

4.2.1        Windows

 

  1. Browse to the install_home\tools\v8 directory and open the v8.ini file in a text editor.
  2. Set the database variable to either db2 or oracle or sqlserver (sqlserver only available from mfa/acm 766 onwards).
  3. Specify the corresponding xdb-connect and xdb-login variables for the database.
    1. Complete the JDBC string by using the <host>:<port>/<service> values.
    2. Specify the database administrator user name and password.
  4. Save and close the v8.ini file.
  5. Optional: Test the configuration.
    1. Run install_home\tools\v8\cmd\v8-service-test.cmd. This command starts the V8 listener in the foreground.
    2. Run install_home\tools\v8\cmd\v8-service-test-client.cmd. This command repeatedly sends a test message <TX> every three seconds to the service and prints the received response <RX>.
  6. Browse to the install_home\tools\v8\cmd directory, right-click the install.bat file, and click Run as Administrator.
  7. From the Start menu, select Administrative Tools > Services, right-click the V8 service, and click Properties.
  8. In the properties window, on the Log On tab, specify an account that has administrator rights and privileges and click Apply.
  9. On the General tab, specify the startup type, start the service, and click OK.
  10. If you change the port number in the v8.ini file, then you must replace the port number 1608 in the psdi.plusa.v8hostname system property:
    1. Log in to Maximo Asset Configuration Manager as an administrator.
    2. Go to the System Properties application, select Filter, and search for the property psdi.plusa.v8hostname.
    3. In the Global Value field, replace <localhost> with either the server host name or the IP address of the computer where V8 is running.
    4. Save the property. To make the change active, click Live Refresh.

  

4.2.2        Linux

  1. Open the install_home/tools/v8/v8.ini file in a text editor.
  2. Change the homev8-cache, and v8-logs variables to the correct file paths, for example:
    • home = /maximo/BDI/v8/resources
    • v8-cache = /maximo/BDI/v8/tmp
    • v8-logs = /maximo/BDI/v8/logs
  3. Change the maxasyncjob-serverhost and maxasyncjob-servername variables to reflect the host address and name of the MXServer that will process asynchronous jobs created by the BDI:
    • maxasyncjob-serverhost = <mxserver-address>
    • maxasyncjob-servername = <mxserver-name 
  4. Set the database variable to either db2 or oracle or sqlserver (sqlserver only available from mfa/acm 766 onwards).
  5. Specify the corresponding xdb-connect and xdb-login variables for the database.
  6. Complete the JDBC string with the <host>:<port>/<service> values.
  7. Specify the database administrator user name and password.
  8. Save and close the v8.ini file.
  9. Create a start script (for only linux only)
  10. Define the following script: 

#!/bin/sh

# chkconfig : 345 99 10

# description : auto start BDI for Maximo

V8_HOME="/maximo/BDI/v8"

JAVA_PROPERTIES=-Dlog4j.configurationFile="$V8_HOME/resources/log4j2.xml"

MEM_ARGS="-Xms4096m -Xmx8192m"

CLASSPATH=$V8_HOME/classes:$V8_HOME/lib/commons-codec.jar:$V8_HOME/lib/db2jcc.jar:$V8_HOME/lib/jansi-1.11.jar:$V8_HOME/lib/log4j-1.2.16.jar:$V8_HOME/lib/log4j-api-2.8.jar:$V8_HOME/lib/log4j-core-2.8.jar:$V8_HOME/lib/oraclethin.jar:$V8_HOME/lib/sqljdbc.jar

case $1 in

start)

cd $V8_HOME

java $MEM_ARGS $JAVA_PROPERTIES -cp $CLASSPATH v8.V8Service ini=$V8_HOME/v8.ini &

;;

stop)

kill -9 `ps -aef | grep 'java $MEM_ARGS $JAVA_PROPERTIES' | cut -d " " -f 6`

;;

esac

Register with chkconfig (for only Linux only)

  1. Save above script and name as bdi
  2. Copy the bdi file to /etc/init.d
  3. chmod 755 /etc/init.d/bdi
  4. chkconfig –-add bdi

4.2.3        Oracle Real Application Clusters (RAC)

When the BDI is to be connected to an Oracle database configured to use real application clusters (RAC) then an additional property needs to be set in the v8.ini file.

This is: v8-maxseq-struct = Nx20

Where N is the number of nodes in the RAC. So for a 3 node Oracle RAC the parameter would be set to:

v8-maxseq-struct = 3x20

The second value (20) indicates the size of the Rowstamp that will be maintained on records in Maximo tables that the BDI monitors. 

As pat of its startup process the BDI will modify the rowstamp triggers on each of the tables it analyses such that the Rowstamp will be set to start with the node number of Oracle RAC node that performs an insert of update on the table.

For example an update to an ASSET record by node 2 in the Oracle RAC will result in a rowstamp = 20000000000000xxxxxx

Where xxxxxx is the next value in the MAXSEQ oracle DB sequence from the cache of sequence values that the node was assigned.

 

This allows the BDI service to monitor a series of rowstamp ranges in order that it can update it's in memory cache when a record is updated or inserted in the Maximo database. 

4.3     Configuring Multiple BDI Instances

Depending on the number and complexity of configuration managed assets residing in the Maximo database it maybe necessary to configure multiple instances of the BDI service.

This can be accomplished by creating copies of and editing a number of directories and files which are used to control the BDI service's behaviour.

4.3.1        Initial Setup

In order to create multiple BDI instances it is first necessary to create copies of certain files and folders for each BDI instance that should be created. The files that should be copied are:

<bdi_home>\v8.ini

<bdi_home>\resources\ (including it's contents)

<bdi_home>\tmp\

<bdi_home>\logs\

 

Standard Directory Structure:

<bdi_home>\

bin\

classes\

cmd\

lib\

logs\

resources\

tmp\

v8.ini

 

Modified Directory Structure (for two BDI instances).

<bdi_home>\

bin\

classes\

cmd\

lib\

instance1\

v8.ini

logs\

resources\

tmp\

 

instance2\

v8.ini

logs\

resources\

tmp\

 

In addition the start up scripts and BDI service install scripts (Windows only) should be duplicated in the <bdi_home>\cmd\ folder.

 
4.3.2      Modifying the Configuration Files

The following changes should be made to the files indicated below for each BDI instance:

1. v8.ini

The following parameters should be modified:

a) v8-instance-name 

The value should be modified such that each instance has a unique name, for example: v8instance1 and v8instance2

b) home

The value should be modified to point to the resources directory of the respective instance. For Linux environments this should be the fully qualified path name, for example /opt/IBM/bdi/instance1/resources

c) v8-cache

The value should be modified to point to the resources directory of the respective instance. For Linux environments this should be the fully qualified path name, for example /opt/IBM/bdi/instance1/tmp

d) service-listener-port 

Each BDI instance must be configured to listen to requests from Maximo on a unique port.

e) msql-mode 

The msql-mode parameter should be set to A|X|E on only one instance. All other instances should be set to A|E

 

2. resources\log4j2.xml

The log4j2.xml file contained within the resources directory for each BDI instance should be edited with the following property changes: 

a) log-path

The log-path should be modified to point to the dedicated log directory for each instance. For linux environments this should be the fully qualified path name, for example: /opt/IBM/bdi/instance1/logs

b) name (optional)

Optionally the name parameter can be modified to give a unique log file name, for example: v8instance1

 

3. resources\v8-select.xml

The v8-select.xml contains a number of sql statements (one per database type supported) which determine which end item and non-end item assets are validated by the BDI instance.

The sql statements can be modified to segregate the assets that each BDI instance is responsible for.

This grouping of assets is down to each individual client but typical examples include creating multiple BDI instances each responsible for one or more Maximo Sites or grouping Assets by Model.

 

The <end-item-select...>, <non-end-item-select...> and <service-monitor-select> can all be modified to group together the assets that each BDI instance will be responsible for processing.

It is advised that each BDI instance is given responsibility for a dedicated group of assets with no overlaps.]

 

Further Details:

 <end-item-select...>  - Determines which End Item Assets are processed by the VREX thread.

An End Item is defined as a configuration managed asset corresponding to the top level build position of a Model.

Note that this should be top level assets (assets with no parent).

 

 <non-end-item-select...>  - Determines which non End Item Assets are processed by the VREX thread.

One typical configuration is to create two BDI instances, one responsible for the processing of End Items, the other for the processing of non-end items. This can be achieved by modifying the end-item/non-end item select queries such that the desired groups of assets are ignore. For example appending 1=2 to the select statement will cause the BDI service VREX thread to ignore this group of assets.

 

<service-monitor-select> - Determines the PLUSAANTRAN records that will be process by the BDI Monitor thread. This can also be modified to restrict the records it will process to a specific subset of configuration managed assets.

 
4.3.3      Modifying the BDI Start Up Files

For each BDI instance the startup scripts and service install files (Windows only) should be modified to specify the specific instance parameters.

The following parameters should be changed:

1. -Dlog4j.configurationFile JVM parameter

This JVM parameter should be modified to point to the instance specific log4j2.xml file. For Linux environments this should be the fully qualified path name to the file.

For example: -Dlog4j.configurationFile="$V8_HOME/instance1/resources/log4j2.xml"

2. "ini" java program argument.

The ini java program argument should be modified to specify the path to the dedicated v8.ini file for the bdi instance.

For example: java $JAVA_PROPERTIES $JAVA_DEBUG -cp $CLASSPATH v8.V8Service ini=$V8_HOME/instance1/v8.ini

 

4.4.1        BDI Initialisation File Parameters

 

The BDI utilises a dedicated initialisation file (v8.ini) which contains a number of parameters essential to its operation and configuration. The file is locating at: <bdi_home>\v8.ini

4.4.1.1    v8-deletes-on-startup

The "v8-deletes-on-startup" parameter controls whether the following tables will be truncated when the BDI service is started. The parameter can be set to Y or N:

PLUSAANTRAN - Records when the BDI validated an ASSET record and acts as a queue of ASSET records to validate which is processed by the BDI monitor thread.

PLUSAANBDISTATUS - Stores the BDI status values for each configuration managed ASSET record.

PLUSANBDIMAPPING - Stores any problem codes determined by the BDI when validating an ASSET record.

4.4.1.2   Memory Settings:

 1. v8-cache-pool-control = x/y/z (default = 400/1/8)

The v8-cache-pool-control parameter is used to control the minimum and maximum number of cache pool objects that the BDI service uses to service requests.

The y parameter is the minimum number of cache pool objects and the cache pool is initialised with this number when the BDI service is started.

The z parameter is the maximum number of cache pool objects. For example if this is set to 8 the BDI Service will be able to service 8 simultaneous requests to validate an ASSET record.

If additional requests are made while all cache pool objects are in use then the request will wait a number of milliseconds before retrying. The number of milliseconds to wait is controlled by the x value.

 

2. v8-cache-mem-mode = x/y (default=64/512)

The v8-cache-mem-mode parameter can be used to tune the memory usage vs. the operational performance of V8.

The default setting of 64/512 is generally suitable for a wide range of setups. This value means that each user connection to the V8 cache can “use” (i.e. hold in memory) a maximum of 512 pages (known as the “Cache Block Limit”) and each page can contain a maximum of 64 Maximo assets (known as the “Cache Block Size”).

4.4.1.3  daemon-pulse-secs = x (default=60) 

The daemon-pulse-secs parameter controls the interval at which the BDI service checks that all independent BDI service threads e.g. The VREX thread, monitor and listener threads and alive and operational.

This should generally be left at it's default setting.

4.4.1.3 v8-options Parameter:

The v8-options parameter is used to alter the functional behaviour of the BDI Service. There a number of options which can be set which are described below:

 

V8 OPTION CODE

DESCRIPTION

AVIATION ONLY

ECP

Switches on Event Calculation Persistence – which means that V8 will calculate and save values for the following fields on the PLUSALFEVENT table: P_LEFT, P_DUECOUNT, P_ENDITEMDUECOUNT, CALCDUEDATE, DATEDUECALC.

P_LEFT = The number of days remaining until the due date or the number of meter units remaining until the due count.

P_DUECOUNT = The due count at which the event (PM) will be due.

P_ENDITEMDUECOUNT = The count at which the event (PM) will become due for the top level end item asset record.

CALCDUEDATE = The estimated due date at which the event (PM) is due. This is equal to the due date for time based events. For meter based events this will be determined from the units remaining and the meter average of the asset.

DUEDATECALC = The date and time when the PLUSALFEVENT record was last updated.

N

MEL

Switches on MEL (Minimum Essential List) rules validation; a MEL problem is reported when the number of installed items is less than the number required. The MEL is defined on the associated Model record.

N

MEL-RL

MEL problems are reported by Label

N

MEL-RP

MEL problems are reported by Position code

N

W&B

Switches on Weight & Balance validation

Y

SRC

Switches on Systems, Roles, and Capabilities evaluation and validation

N

FLB

Switches on Flight Log Book validation (e.g. status = Aircraft is Grounded)

N

OWO

Switches on monitoring for Orphan Work Orders; when a Task Card (i.e. PM) is closed by the user it is possible that some open work orders remain, “orphaned” from their PM

N

OWJ

Switches on monitoring for revised Job Plans; when a Job Plan is revised and an open work order exists

with this Job Plan applied then this situation is raised as a problem code by the BDI

N

         OWT

Switches on monitoring for revised Task Cards (PMs); when a Task Card (PM) is revised and an open work order exists which was generated from this Task Card (PM)  then this situation is raised as a problem code by the BDI

N
         OMP Switches on monitoring for expired OMPs; OMP = OEM Maintenance Plan; OEM = Original Equipment Manufacturer Y

MPM

Switches on monitoring for invalid mission flags on FLBs; MPM = Mission Profile-based Maintenance

Y

TSX

Switches on Time Since Repair/Overhaul/Inspection – which means that V8 will calculate and save values for the following fields on the PLUSAASSETTIMESINCE table: SINCELASTREPAIR, SINCELASTOVERHAUL, SINCELASTINSPECT, SINCELASTINSPECT2, SINCEINSTALL, LIFETODATE

N

XPM

See below

N

-TRPNR

Switches off the Part Number Range capability associated with Technical Publications; this option is mandatory when using V8 with ACM

N

SFT

Switches on Soft Task logic

N

PME

Switches on PM Extensions logic

N

SHL

Switches on Shelf Life logic

Y

 

Multiple options can be used together, for example, in the v8.ini file:  v8-options = ECP|-AJRPM

 

XPM Explanation

Evaluating whether a PM should be activated:

Scenario #1 – the asset is installed and a ON-DEACTIVATE action exists where the secondary PM is the PM in question.

Scenario #2 – the asset is uninstalled and an OFF-DEACTIVATE action exists where the secondary PM is the PM in question.

In both cases, V8 looks for such an appropriate ON-DEACTIVATE or OFF-DEACTIVATE action to disallow the activation. The XPM option adds both ACTIVATE and DEACTIVATE to the search criteria for a disallowing action.

 

The following “-AJxxx” options codes can be used to disable any of the Asynchronous Jobs that the BDI Service creates. Note that each code starts with a dash (“-“) character because they are “switch off” (negative) options, the default being “on” in all cases.

 

V8 OPTION CODE

ASYNC JOB NAME

DESCRIPTION

-AJCPM

PLUSABDI_CREATEPM

Create missing PM for Asset {0} in Site ID {1} from Master PM {2}

-AJRPM

PLUSABDI_REVISEPM

Update PM {0} in Site {1} from Master PM {2} Revision {3}

-AJPMS

PLUSABDI_CHGPMSTATUS

Change status of PM {0} in Site {1} to {2}

-AJPMW

PLUSABDI_GENERATEPMWO

Generate Work Order from PM {0} in Site {1}

-AJSEI

PLUSABDI_CREATESEIWO

Create Work Order for Missing Mandatory Position: {0} - {1}

-AJTPM

PLUSABDI_CREATETRPM

Create PM for Asset {0} in Site {1} from Technical Record {2}

-AJMEL

PLUSABDI_CREATEMELWO

Create Work Order for MEL: {0} - {1}

-AJWBV

PLUSABDI_CREATEWBWO

Create Work Order for W&B Variance: {0} - {1}

-AJFDS

PLUSABDI_CHGFLBDISCSTATUS

Change status of discrepancy {0} to {1}

 

4.4.2        BDI Initialization File Encryption

It is possible to encrypt a value (or multiple values) within the v8.ini file.

To do this, first “markup” the value(s) to be encrypted with a double-& prefix. For example, to encrypt the database password, edit the v8.ini file, and change the xdb-login parameter, as follows:

 

xdb-login-oracle = maximo/&&maxpwd (where maximo is the username and maxpwd is the password)

To encrypt the database username as well, change the xdb-login-oracle parameter to:

 

xdb-login-oracle = &&maximo / &&maxpwd

 

(note the required space delimiter after &&maximo, and the optional space before &&maxpwd)

 

Save and close v8.ini.

Now start VEX.

At the command prompt, type: encrypt install_home\tools\v8\v8.ini and hit enter.

If you open v8.ini again, you will see that any values marked for encryption are now encrypted.

 

5       Appendix

5.1     BDI Status and Problem Codes

5.1.1        BDI Status Codes

 

Status

Description

OK

 

Indicates that there are no reported problems with the Asset.

AOG

 

Indicates an Aircraft on Ground condition exists due to an un-deferred discrepancy in the Flight Log Book for the Asset. NB. This is only relevant in Aviation environments.

INVALID

 

Indicates that the configuration status of the Asset is invalid. The problems reported will indicate why the status is considered invalid.

ALERT

 

Indicates that the configuration status is ok but there are non-critical problems which the user may need to be aware of.

 

5.1.2        BDI Problem Codes

The RED codes are serious problems and the Asset’s status will be “INVALID”.

The AMBER codes are less serious problems that may affect the operation of the Asset. This includes approaching maintenance tasks that will require action in the short term. The Asset’s status will be “ALERT”.

The GREEN codes are created when the BDI is validating an “alternative configuration”. When the BDI is run in “update” mode, these problems are automatically corrected (e.g. Maintenance Events and Build Positions are created or removed).

The BLUE codes are for information only.

5.1.2.1    RED Codes

AOG – Aircraft is AOG [Aircraft On Ground]

  • The active FLB (Flight Log Book) for the aircraft has a status of GROUNDED or UNKNOWN, or there is an open Ticket with status of AOG.

BMR – Invalid Position

  • The Build Position is invalid due to applicability rules or Technical Publications.
  • The non-serialized position has a negative quantity, or a quantity less than the minimum allowable quantity, or a quantity exceeding the maximum allowable quantity.

EMR – Invalid Position for the EISUOC

  • The Build Position is invalid due to end item serial effectivity rules (i.e. regarding the Build Position’s applicability to the End Item Serial Usable On Code).

SIR – Invalid Part Number Installed

  • The Part Number/CM Item installed in the Build Position is invalid due to applicability rules or Technical Publications

SSR – Duplicate Part and Serial Number.

  • The Asset installed into the position has the same Part Number/CM Item and Serial Number as another Asset within the system.

ISR – Invalid Install / Remove History

  • An overlapping Install-Remove history was found for the Asset or a Position on the Asset.

SMM – Missing Mandatory Position

  • The mandatory Build Position is missing. If the BDI is running in update mode, the position will be created but will then have an SEI status [Empty Mandatory Position].

SEI – Empty Mandatory Position

  • The mandatory Build Position is empty.

EIR – Invalid Part Number Installed for the EISUOC

  • The Part Number installed in the Build Position is invalid due to end item serial effectivity rules (i.e. regarding the Part Number’s applicability to the End Item Serial Usable On Code).

XDP – Invalid Part Installed

  • The Part Number installed in the Build Position is invalid due to a cross-structural or higher-part applicability rule.

ENR – Event Needs Review

  • The Maintenance Event created by the BDI needs to be reviewed for validity of the Active Date.

EBD – Event Beyond Due

  • The open Maintenance Event has exceeded its Due date or Meter Reading.

MEL – Minimum Equipment List

An End Item has a MEL rule that has not been satisfied

The BDI will generate a MEL BDI code and a MEL work order when:

  • the v8-options setting in the v8.ini file contains “MEL”
  • the asset is an end item
  • the asset’s Model has its MEL flag set to true
  • note: if the MEL tab does not appear, check the Security Group  “Models (CM)” application  “Hide MEL Tab on Model application” option
  • there is a MEL rule associated with the assets’s Model that has not been satisfied

 

W&B – Weight & Balance Variance (Maximo for Aviation only)

A Aircraft has a Weight or Balance variance exceeding allowable limits

The BDI will generate a W&B BDI code and a “Weigh Aircraft” work order when:

  • the v8-options setting in the v8.ini file contains “W&B”
  • the asset is an end item
  • the asset’s Model has its W&B flag set to true
  • the IsInLimits flag on the latest applied* PLUSMWOASTWB record (by date, related to the AssetNum and SiteId of the asset) is set to false

* a PLUSMWOASTWB record is considered to be “applied” if its WONum is null, or the Status of the Work Order is Complete or Closed

 

5.1.2.2    AMBER Codes

    EBA – Event Beyond Alert

    • The open Maintenance Event has exceeded its Alert Date or Meter Reading.

    EBW – Event Beyond Warning

    • The open Maintenance Event has exceeded its Warning Date or Meter Reading.

    NAD – Non-AOG Discrepancy

    • An active FLB for the aircraft has a status of LRTS (Limited Release to Service) or DRTA (Deferred Release to Service), or there is an open Ticket with a non-AOG status.

    SED – Empty Mandatory Deferred Position

    • The mandatory Build Position is empty but has an associated Deferred Work Order.

    OWO – Open Work Order Exists where the associated PM is INACTIVE

    • An open work order exists where the associated PM has been made INACTIVE.

    OWJ – Open Work Order Exists where the Job Plan applied to it has been revised.

    • An open work order exists where the Job Plan applied to it has subsequently been revised.

    OWT – Open Work Order Exists where the PM from which it was generated has been revised.

    • An open work order exists where the PM from which it was generated has subsequently been revised.

    SBA – Soft Task/PM Beyond Alert

    • The open Soft Task Maintenance Event has exceeded its Alert Date or Meter Reading.

    SBW – Soft Task/PM Beyond Warning or Due

    • The open Soft Task Maintenance Event has exceeded its Warning or Due Date or Meter Reading.

    5.1.2.3    GREEN Codes

    EMC – Event Missing

    • A required Maintenance Event is missing.  If the BDI is running in update mode, the Maintenance Event will be created.

    EID – Extra Event

    • The Maintenance Event is not applicable.  If the BDI is running in update mode, the Maintenance Event will be removed (if there is no associated Work Order).

    BMD – Empty Extra Position

    • An empty Build Position is invalid due to applicability rules or Technical Publications. If the BDI is running in Update mode, this Build Position will be removed.

    EMR – Invalid Position for the EISUOC

    • The empty Build Position is invalid due to end item serial effectivity rules (i.e. regarding the Build Position’s applicability to the End Item Serial Usable On Code). If the BDI is running in Update mode, this Build Position will be removed.

    SMO – Missing Optional Position

    • An optional Build Position that is required by the CM rules is missing.  If the BDI is running in mode, the Build Position will be created.

     

    5.1.2.4    BLUE Codes

    SEO – Empty Optional Position

    • Empty Optional Positions are treated as OK.

     

     

    5.2     BDI Crontasks and Asynchronous jobs

    5.2.1        BDI Asynchronous Job Processing Crontask

    The Maximo ACM system comes with a pre-configured crontask which processes asynchronous jobs generated by the BDI service. There are multiple instances of the crontask configured out of the box, one per job type.

    Each crontask instance is configured with a 10 second schedule by default.

    The crontask name is: PlusABDIAsyncImmediateJobCron

    In environments with a large number of Assets where there is the potential for the creation of large numbers of asynchronous jobs by the BDI service then extra crontask instances can be configured.

     

    5.2.2        List of Asynchronous Jobs created by the BDI

    Job Name

    Description

    Class Name

    PLUSABDI_CREATEPM

    Creates missing PMs from Master PMs based on applicability

     

    psdi.plusa.app.asset.virtual.asyncjobs.

    PlusACreateMissingPMAsyncJobHandler

     

    PLUSABDI_REVISEPM

    Updates an associated PM from the Master PM. If revsion functionality is enabled then revise the PM.

    psdi.plusa.app.asset.virtual.asyncjobs.

    PlusARevisePMAsyncJobHandler

     

    PLUSABDI_CHGPMSTATUS

    Changes the status of the PM to that of the supplied parameter

    psdi.plusa.app.asset.virtual.asyncjobs.

    PlusAChangePMStatusAsyncJobHandler

     

    PLUSABDI_GENERATEPMWO

    Generates a work order for the specified PM

    psdi.plusa.app.asset.virtual.asyncjobs.

    PlusAGeneratePMWOAsyncJobHandler

     

    PLUSABDI_CREATESEIWO

    Creates a work order for and empty mandatory position

     

    psdi.plusa.app.asset.virtual.asyncjobs.

    PlusACreateSEIWOAsyncJobHandler

     

    PLUSABDI_CREATETRPM

    Creates missing PMs for Technical Records based on applicability

     

    psdi.plusa.app.asset.virtual.asyncjobs.

    PlusACreateMissingTRPMAsyncJobHandler

     

    PLUSABDI_CREATEMELWO

    Creates a work order for a MEL condition

     

    psdi.plusa.app.asset.virtual.asyncjobs.

    PlusACreateMELWOAsyncJobHandler

     

    PLUSABDI_CHGFLBDISCSTATUS

    Changes the status of an FLB discrepancy record (PLUSALFLBDISCREPANCY)

     

    psdi.plusa.app.asset.virtual.asyncjobs.

    PlusAChangeFLBDiscrepancyStatusAsyncJobHandler

     

    PLUSABDI_CHGWOSTATUS

    Changes the status of a Work Order

    psdi.plusa.app.asset.virtual.asyncjobs.

    PlusAChangeWOStatusAsyncJobHandler

     

     

     

    5.3     Configuration Rule Applicability Matrix

    The BDI stores the majority of its configuration rules in the PLUSACMAPPLE table. The following matrix gives information on the types of rules available and the relationships to other records within the system:

     

     Rule Description

    Apple Type

    RX1

    RX2

    RX3

    RY1

    RY2

    RY3

     Position applicability to Path

    X1

    Path

     

     

    Build

     

     

     Position applicability to Variation

    XF

    Config

     

     

    Build

     

     

     Position applicability to Variation E-I SR

    XE

    SR

     

     

    Build

     

     

     Label applicability to Path

    X4

    Path

     

     

    Build

    Label

     

     Label applicability to Variation

    X5

    Config

     

     

    Build

    Label

     

     CM Item applicability to Path

    H1

    Path

     

     

    Build

    CM Item

     

     CM Item applicability to another CM Item

    H2

    Build

    CM Item

     

    Build

    CM Item

     

     CM Item applicability to another CM Item SR

    H3

    Build

    CM Item

    SR

    Build

    CM Item

     

     CM Item applicability to Variation

    HO

    Config

     

     

    Build

    CM Item

     

     CM Item applicability to E-I SR

    HN

    SR

     

     

    Build

    CM Item

     

     Master PM applicability to Path

    C1

    Path

     

     

    Build

    CM Item

    Master PM

     Master PM applicability to Variation

    C2

    Config

     

     

    Build

    CM Item

    Master PM

     Master PM applicability to E-I SR

    C3

    SR

     

     

    Build

    CM Item

    Master PM

     Formula applicability to Path

    C4

    Path

     

     

    Build

    Meter

    Formula

     Formula applicability to Variation

    C5

    Config

     

     

    Build

    Meter

    Formula

     Formula applicability to E-I SR

    C6

    SR

     

     

    Build

    Meter

    Formula

     

    Key:

    Build = PLUSACMBUILD.PLUSACMBUILDID

    Config = PLUSACMCONFIG.PLUSACMCONFIGID

    CM Item = PLUSACACAT.PLUSACACATID

    Master PM = MASTERPM.MASTERPMID

    Meter = METER.METERID

    Formula = PLUSACMFORMULA.PLUSACMFORMULAID

    Label = PLUSACMLABEL.PLUSACMLABELID

    Path = PLUSACMPATH.PLUSACMPATHID

     

     

    5.4     Troubleshooting

    5.4.1        Windows

    5.4.1.1    Troubleshooting the BDI Windows Service

    If the V8 service will not start, the most common problem is that the 64-bit BDI Service is finding a 32-bit Java Runtime Environment (JRE).

    The v8\bin folder contains 2 files, v8.exe and v8w.exe. These are the (default) 64-bit versions.

    You can either:

    1. Substitute 32-bit versions of v8.exe and v8w.exe, copied from the v8\bin\32-bit folder, or
    2. Make certain that V8 finds a 64-bit JRE.

     

    Option (i) is not recommended, except as an experiment to see if V8 will start.

     

    Option (ii) can be done as follows:

     

    1. Open the file install (…).bat file in a text editor.
    2. Add a line underneath --Jvm=auto ^ that says:
      • --JavaHome= C:\Java\jreX.X.X_XX\bin ^
      • where the JavaHome path specifies a 64-bit JRE (which you may need to download and install as necessary).

     

    1. Before (re)running install (…).bat make sure you run delete (…).bat first

     

    V8 uses the Apache Commons Procrun application to wrap the Java V8 application as a Windows Service

    >>> Note: v8.exe (in install_home\tools\v8\bin) is a copy of Apache procrun.exe, so any documentation that applies to procrun.exe also applies to v8.exe

    See http://commons.apache.org/proper/commons-daemon/procrun.html for documentation on procrun.exe

    • A common problem with procrun is that it cannot find msvcr71.dll
    • Try starting the V8 service manually:
      1. Create a cmd.exe shortcut on your desktop
      2. Alt-click on the cmd.exe shortcut and Run as Administrator
      3. Then enter: net start "V8" and see if there are any error messages

     

    5.4.1.2    How to Kill / Delete the V8 Service if it won’t Stop

    • Create a cmd.exe shortcut on your desktop
    • Alt-click on the cmd.exe shortcut and Run as Administrator
    • Then enter: sc queryex V8 and make a note of the PID
    • Then enter: taskkill /f /pid <PID>
    • Now delete as normal by running delete (…).bat

     

    5.4.2        Cache Synchronization

    5.4.2.1    Troubleshooting Maximo / V8 Synchronization

    Just before the BDI starts a “run” (i.e. each BDI run processes a single end item or uninstalled assembly) the BDI validates that its internal cache is synchronized with the Maximo database, and selectively updates itself where required.

    The synchronization schema is defined in <bdi_home>\resources\xdb-sync.xml.

    The VREX thread, each time it starts, initiates a BDI run for each end item or uninstalled assembly, one after another, until all required assets are processed.

    The BDI prints the following header record to the log after completing each run:

    [VMStatus][VFBOM] --- assetnum --- hh:mm:ss [0.000 secs] a|b|c|d|e|f - x|y

    The a, b, c, d, e, f, and x, y values can be interpreted as follows:

     

    Value

    Description

    a

    Number of Models that required resynchronization.

    b

    Number of Apple Rules that required resynchronization.

    c

    Number of Paths that required resynchronization. Note: a “Path” is a link between a model install point and an installable part number.

    d

    Number of Events that required resynchronization.

    e

    Number of Technical Publications that required resynchronization.

    f

    Number of Assets that required resynchronization.

    x

    Number of Build Positions (i.e. PLUSACMBUILD records) processed. This closely correlates to the number of assets processed, but some positions might be empty.

    y

    Number of Page Swaps required by the cache (a lower number is better with regards to overall performance).


    #acm

    Statistics

    0 Favorited
    14 Views
    0 Files
    0 Shares
    0 Downloads