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)

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.

 

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.

 

 

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

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.

 

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).

 

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.

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.

 

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

 

 

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.

  

1. Open the install_home/tools/v8/v8.ini file in a text editor.
2. Change the home, v8-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. 

 

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

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.3.4 Configuring Maximo to use multiple BDI Instances
By default Maximo will attempt to communicate with the BDI instance based on the value of the system property: psdi.plusa.v8hostname
For the purposes of load balancing or failover the system can be configuring to use multiple BDI instances by adding records to the table:

PLUSABDILISTENERS

The following table attributes can be set:
SERVERHOST - The server name or IP address where the BDI instance is running.
LISTENERPORT - The port which the BDI instance is configured to use.

For failover:
Multiple rows can be added to the table. When a user chooses to validate an Asset using the BDI Status dialog the system will attempt to contact a BDI instance and if unsuccessful will attempt to use an alternative.

For load balancing:
The table also contains the following attributes:
ITEMSETID
ORGID
SITEID

If these values are populated then the system will only use those instances which match with those of the corresponding Asset.

NB. The PLUSABDILISTENERS table needs to be populated by a sql script as there is no user interface in ACM/Aviation 7.6.x. 
In Maximo Mange with ACM/Aviation on the Maximo Application Suite a dialog was added to enable this using the UI in the BDI Queue Status application.

 

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}

 

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.

 

 

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.

 

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.

 

 

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.

 

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

 

 

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.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).

 

3. 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:
  5. Create a cmd.exe shortcut on your desktop
  5. Alt-click on the cmd.exe shortcut and Run as Administrator
  5. Then enter: net start "V8" and see if there are any error messages

• This blog post may be helpful: http://www.artofsolving.com/node/49.html

 

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.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).

​

#MaximoEAM
#acm
#AssetandFacilitiesManagement
#Maximo