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 Actions

4  BDI Configuration

4.1.    Overview

4.2.    BDI Configuration Settings

5 BDI Queue Status Application

6 BDI Grafana Dashboard

7 BDI Custom Resource Settings 

8 Appendix

8.1     BDI Status and Problem Codes

8.1.1      BDI Status Codes

8.1.2       BDI Problem Codes

8.1.2.1   Invalid (RED) Codes

8.1.2.2   Alert (AMBER) Codes

8.1.2.3   Information (GREEN) Codes

8.2     BDI Cron tasks and Asynchronous jobs

8.2.1   List of Asynchronous Jobs created by the BDI

8.3     Configuration Rule Applicability Matrix

8.4     Troubleshooting

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

The Build Data Interpreter (BDI) is a system component which is deployed as part of the Maximo Aviation and Maximo Asset Configuration Manager products. It is responsible for verifying and ensuring the conformity of operational modifications to configuration-managed assets in accordance with the reference data and configuration rules defined within an associated model and maintenance plan.

The BDI can be executed either manually for a designated asset hierarchy, employing the BDI Status interface within the Aircraft or Equipment application (Aviation) or the Assets (CM) application (ACM), or it can operate automatically in the background according to a pre-established, time-based schedule. Furthermore, particular transactions executed within the system have the capability to trigger an asynchronous invocation of the BDI.

Overview of main BDI responsibilities:

• Examines configuration-managed assets on a position-by-position basis, ascertaining their adherence to the configuration rules defined in the associated Model.
• Provides a comprehensive status for an asset, which can be viewed in the BDI Status dialogue interface, and identifies instances of non-conformity by issuing problem codes and corresponding details.
• Assesses the maintenance program for an asset and causes the creation of work orders. derived from preventive maintenance records (PMs or Task Cards), at a pre-determined alert threshold.

 

The BDI is an independent service which runs in one or more dedicated pods separate from the main Maximo enterprise application (server bundle pods).

A single instance (pod) is deployed automatically, using default settings, when either Aviation or ACM is activated as a component of Manage within a MAS Workspace.

This automatic deployment is performed by a dedicated BDI entity manager (operator) in combination with BuildDataInterpreter operands (Open Shift Custom Resources).

The BuildDataIntrepreter custom resources are created by the Manage Workspace entity manager.

The BDI pods communicate and synchronise directly with the Maximo database and also insert and update data in the BDI status related tables within the Maximo database.

In addition, the BDI provides a simple API which allows synchronous communication from the Maximo Manage application when a request is made by a user to validate/update the configuration status of an asset.

The BDI does not utilise Maximo business objects (MBOs) directly for data updates, primarily due to performance considerations. As a result, when a transaction necessitates the employment of MBOs – such as generating a work order from a preventive maintenance (PM) record – the BDI creates an asynchronous job, which is subsequently processed autonomously by a series of Maximo Cron Task instances.

This approach enables the BDI to deliver a status outcome without necessitating a delay for the completion of the aforementioned asynchronous tasks, thus optimising the overall system performance.

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

The BDI status dialog is accessible in the Aviation and Equipment applications in Maximo Aviation or the Assets (CM) application in ACM.

It can be opened  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 make a synchronous call to the BDI to validate the asset and update its configuration status.

The BDI status window contains three sub tabs.

 

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

It gives an overall configuration status as well as information on when it was last validated.

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 detailed list with explanations) together with a narrative describing the problem.

 

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

It gives the user the ability to validate a different configuration by using the “selected” checkboxes and the "Validate Configuration" button.

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

The user can also change the configuration(s) applied to the asset by clicking the “Apply Configuration” button. The selected configurations will then be made the current configuration of the Asset.

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

The asynchronous job records are stored in the MAXASYNCJOB table and are processed by a dedicated group of Maximo Cron Tasks.

Job status values:

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

 The BDI Crontask is named "PlusABDIAsyncImmediateJobCron". By default there is one crontask instance per job type that can be created by the BDI.

The type of job an instance is responsible for processing is controlled by the "jobnames" parameter. Additional Cron Task instances can be created if the business requires jobs to be processed more quickly or if there is a bottle neck where many jobs are queued.

4       BDI Configuration

4.1 Overview

A single instance of the BDI is automatically deployed, with default settings, when Manage is activated in a MAS Workspace.

Additional instances of the BDI can be configured if it is determined that a single instance is not validating all configuration managed assets frequently enough (as required by the business users).

The individual settings of each instance can be modified by clicking the "View" link.

Before configuring additional instances it is advised that the various settings which control the BDIs operation are first analysed to determine if changes can be made to increase the throughput and alleviate bottlenecks.

The user interface for the BDI settings, in the Manage Workspace activation page, is shown below:

 Individual BDI Instance settings can be altered in the dialog shown below.

Each BDI setting is detailed below:

Name:

A unique name for the BDI instance. It is recommended the default value is used.

MAx MeMORY:

The maximum Java heap memory that is assigned to the BDI instance. The BDI application is a web application deployed to Websphere Liberty.

This setting is used to set the '-Xmx' JVM option used with the Liberty application server.

ACM and Aviation Options:

The Aviation/ACM Options parameter is used to alter the functional behaviour of the BDI. Which one is used depends on which product is enabled. There a number of options which can be set which are described below:

OPTION CODE	DESCRIPTION	AVIATION ONLY
ECP	Switches on Event Calculation Persistence – which means the BDI 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 the BDI 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 the BDI with ACM	N
SFT	Switches on Soft Task logic	N
PME	Switches on PM Extensions logic	N
SHL	Switches on Shelf Life logic	Y

 

 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, the BDI 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.

BDI 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}

  

Cache Settings:

Cache settings are used to control the memory usage of "cache" objects and the pool where they are taken from.

A cache object is taken from a pool to service the request to validate an asset. It contains data cached from the Maximo database including Model, asset and preventive maintenance data.

Increasing the amount of memory used by a cache can improve performance but the trade off is increased memory consumption.

POOL MIN:

The minimum number of cache pool objects retained in the cache pool. It is initialised with this number when the BDI starts.

POOL MAX:

The maximum number of cache pool objects. For example if this is set to 8 the BDI instance 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 pool max should be >= (monitor.threads + vrex.workers + 1) to allow for enough cache objects to service requests from these processes simultaneously (detailed below).

PAGES and ASSETS PER PAGE:

These parameters can be used to tune the memory usage vs. the operational performance of the BDI.

The default settings of 256 and 512 is generally suitable for a wide range of setups. This value means that each BDI cache pool object (used to service BDI requests) can “use” (i.e. hold in memory) a maximum of 256 pages (known as the “Cache Block Limit”) and each page can contain a maximum of 512 Maximo assets (known as the “Cache Block Size”) to give a total of 131072 assets.

AV MEM MODE:

The "AV Mem Mode" is used to control the number of meter readings and PM records which can be cached in memory.

Monitor Settings:

The "Monitor" settings are used to control if, and how often, the BDI polls the BDI queue table (PLUSAANTRAN) looking for assets to validate. There is a separate configuration setting (described below) which determines the SQL executed to identify the pending records awaiting processing.

ENABLED:

Determines if the Monitor process is enabled.

THREADS:

The maximum number of assets in the queue which will be processed in parallel. Increasing this setting will mean more queued records can be processed simultaneously but will increase CPU load.

PULSE SECONDS:

How often the BDI will poll the BDI queue table looking for assets to validate.

CLEAN UP DAYS:

The number of days before completed BDI Queue records (those with a status of COMPLETE or ERROR) will be automatically deleted.

VREX SETTINGS:

The "VREX" process is used to process configuration managed assets on a fixed schedule in the background. This ensures that all configuration managed assets are validated regularly (how often is typically a business decision).

ENABLED:

Determines if the VREX process is enabled.

WORKERS: (From MANAGE 8.6 onwards)

Controls the number of Assets validated in parallel by the VREX process.

RUN ON START:

Controls whether the VREX process is executed immediately when the BDI pod is started.

PULSE MINUTES:

Controls how often the VREX process is executed. The default is every 180 minutes (3 hours).

START TIME:

Instead of executing the VREX process every x minutes the start time parameter can be used to specify a time of day at which the VREX process should be executed. This overrides the Pulse Minutes parameter.

ASYNC JOB SETTINGS:

DELETE ON START-UP:

This parameter controls whether the completed MAXASYNCJOB records are deleted when the BDI is started.

RETENTION DAYS:

The number of days which completed MAXASYNCJOB records, created by the BDI, are retained before being automatically deleted.

OTHER SETTINGS:

LOG LEVEL:

Controls the logging verbosity of the BDI. A change to this value is deployed automatically without requiring the restart of the BDI pod.

SELECT:

The Select parameter is a series of SQL statements in an XML format. It is used to control which records the VREX and Monitor processes identify for processing.

It contains DB specific sql which determines:

1) The end items which will be validated by the VREX process: <end-item-select-{dbtype}>

2) The non-end items which will be validated by the VREX process: <non-end-item-select-{dbtype}>

3) The BDI queue records waiting for processing: <service-monitor-select>

4) The Assets the BDI will consider for inclusion in its cache: <cache-select>

5) The Master PM records the BDI will consider as part of validating an asset: <masterpm-select>

5 BDI Queue Status Application

The BDI Queue Status application gives visibility on the BDI Queue. It shows the status of all records, how long they took to process and also if there was an error information about the stack trace produced as a result of an exception.

This can be useful in helping expediting the resolution of BDI errors.

5.1 BDI End Points

The BDI Queue Status Application contains an action "Manage BDI End Points" which opens a dialog containing the settings used to determine the service used for BDI API calls.

A record is created in this table by default, on Aviation/ACM installation, assuming there are no existing records in the table.

If more than one BDI instance has been configured the dialog can be used to add these additional instances such that they will be candidates for BDI API requests. This can be useful if the number of simultaneous BDI requests, made from the BDI Status dialog by Maximo users, becomes too large for a single BDI instance to handle.

A Maximo Part Set, Organization or Site can be associated with each End Point definition to cause requests for Assets, which match those values, to be routed to that particular instance. This can be useful for load balancing API requests.

The port should always be configured as 9443 and the SSL toggle box set to "ON".

The service host takes the form of: {instanceId}-{workspaceId}-{bdi-instance-name}.mas-{instanceId}-manage.svc

6 BDI Custom Resource Settings 

*From MANAGE 8.6 onwards

Two "low level" BDI settings can be configured by updating (or patching) the "bdiConfigurations" section of the ManageWorkspace Custom Resource.

These settings would be set by an Open Shift administrator.

• imagePullPolicy: Determines when the BDI image will be retrieved from the IBM Entitled Registry. By default the value is: IfNotPresent. This setting is mainly used for internal development purposes.
• enableRoute: Determines whether an external Route is created, by the BDI entity manager, to the BDI OpenShift service (note this is not required for API requests from Maximo as the internal service is utilised for this purpose). An external route can be useful for examining the BDI API documentation (Swagger docs) or making BDI API calls from an external system. Note that a valid MAS 'x-access-token' cookie is required for external BDI requests. The default is for the Route to be enabled.

Because the "bdiConfigurations" property of the ManageWorkspace custom resource is recorded in an Array it is recommended to update the yaml definition directly in the Open Shift console if modifying any of these additional properties.

If an OC patch command is used all of the properties in the bdiConfiguration array element must be specified.

7 BDI Grafana Dashboard

*From MANAGE 8.6 onwards

With Maximo Aviation or ACM enabled a Grafana Dashboard will be automatically deployed to enable monitoring of key BDI metrics. 

This assumes the Promethus and Grafana tools are installed and configured.

The MAS Ansible Devops collection contains a role to automate the deployment of these tools.

The key metrics displayed in the dashboard are described below:

Validation Queue Back Log:

Displays the number of records in the BDI queue with a status of PENDING or QUEUED. A sustained large number indicates that the monitor process may be failing to keep up with the rate at which records are being placed into the queue by the system.

Solutions to this maybe increasing the number of monitor threads or configuring additional BDI instances.

API Validation Requests/min:

The number of requests to validate an asset per minute received by the BDI API. The API requests would normally come from usage of the Validate Configuration button in the BDI Status dialog.

BDI DB ConnectionS:

Displays the current number of open database connections created by the BDI. The BDI operates a JDBC connection pool where new connections are opened depending on simultaneous validation request.

Connections which are open but have not been used in the last 5 minutes will be automatically closed.

VM STATUS POOL SIZE:

Displays the current number of cache objects in the cache pool used to service BDI requests.

HEAP MEMORY USAGE:

Displays Java Heap memory usage for all BDI pods.

CPU USAGE:

Displays CPU usage for all BDI pods.

ASYNC DB WRITER QUEUE SIZE:

Displays the number of asynchronous database updates waiting for execution. Certain database updates performed by the BDI are performed asynchronously in order to optimize performance.

If the number of records displayed here is consistently high and never falls to zero it could indicate a requirement for additional BDI instances.

ASYNC JOB WRITER QUEUE SIZE:

Displays the number of asynchronous jobs waiting to be executed for insertion into the Maximo database.

If the number of records displayed here is consistently high and never falls to zero it could indicate a requirement for additional BDI instances.

8       Appendix

 

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.

8.1.2.1    Invalid (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 BDI Options setting contains the value “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 BDI Options setting contains the value “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

 

8.1.2.2    Alert (AMBER) Codes

EBA – Event Beyond Alert

• The open Maintenance Event (PM or Task CArd) 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.

8.1.2.3    Information (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.

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

 

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

The RX1/RX2/RX3/RY1/RY2/RY3 fields store the ids of the corresponding records as shown in the Matrix.

 

Configuration Rules

Rule Description	Apple Type	RX1	RX2	RX3	RY1	RY2	RY3	Explanation
Position applicability to Path	X1	Path			Build Position			Defines the applicability of the selected build position dependent on the path in which it sits as determined by the sub model system on system configuration.
Position applicability to Variant Configuration	XF	Configuration			Build Position			Defines the applicability of the selected build position to the current variant of the Asset.
Position applicability to End Item Serial Range	XE	Serial Range			Build Position			Defines the applicability of the selected build position based on the serial number of the end item asset in which the sub assembly asset is installed.
Label applicability to Path	X4	Path			Build Position	Label		Defines the applicability of the selected label dependent on the path in which it sits as determined by the model system on system configuration.
Label applicability to Variant Configuration	X5	Configuration			Build Position	Label		Defines the applicability of the selected label to the current variant of the Asset.
CM Item applicability to Path	H1	Path			Build Position	CM Item		Defines the applicability of the selected CM Item, in a build position, dependent on the path in which it sits as determined by the sub model system on system configuration.
CM Item applicability to another CM Item	H2	Build Position	CM Item		Build Position	CM Item		Defines the applicability of the selected CM Item in the selected build position to that of another CM Item in another build position. This is used to establish a cross part effectivity rule.
CM Item applicability to another CM Item Serial Range	H3	Build Position	CM Item	Serial Range	Build Position	CM Item		Defines the applicability of the selected CM Item in the selected build position to that of another CM Item and the serial range in another build position. This is used to establish a cross part effectivity rule dependent on serial number.
CM Item applicability to Variant Configuration	HO	Configuration			Build Position	CM Item		Defines the applicability of the selected CM Item in the select build position to the current variant of the Asset.
CM Item applicability to to End Item Serial Range	HN	Serial Range			Build Position	CM Item		Defines the applicability of the selected CM Item in this position based on the serial number of the end item asset in which the sub assembly asset is installed.
Master PM applicability to Path	C1	Path			Build Position	CM Item	Master PM	Defines the applicability of the selected Master PM, in a build position, dependent on the path in which it sits as determined by the sub model system on system configuration.
Master PM applicability to Variant Configuration	C2	Configuration			Build Position	CM Item	Master PM	Defines the applicability of the selected Master PM to the current variant of the Asset.
Master PM applicability to End Item Serial Range	C3	Serial Range			Build Position	CM Item	Master PM	Defines the applicability of the selected Master PM based on the serial number of the end item asset in which the sub assembly asset is installed
Formula applicability to Path	C4	Path			Build Position	Meter	Formula	Defines the applicability of the selected Formula, in a build position, dependent on the path in which it sits as determined by the sub model system on system configuration.
Formula applicability to Variant Configuration	C5	Configuration			Build Position	Meter	Formula	Defines the applicability of the selected Formula to the current variant of the Asset.
Formula applicability to End Item Serial Range	C6	Serial Range			Build Position	Meter	Formula	Defines the applicability of the selected Formula based on the build position and serial range of the end item asset in which the sub assembly asset is installed.

 

Key:

Build Position = PLUSACMBUILD.PLUSACMBUILDID

Configuration = PLUSACMCONFIG.PLUSACMCONFIGID

CM Item = PLUSACACAT.PLUSACACATID

Master PM = MASTERPM.MASTERPMID

Meter = METER.METERID

Formula = PLUSACMFORMULA.PLUSACMFORMULAID

Label = PLUSACMLABEL.PLUSACMLABELID

Path = PLUSACMPATH.PLUSACMPATHID

  

#Aviation
#Maximo
#acm
#maximo
#MaximoEAM
#MAS
#manage
#bdi
#AssetandFacilitiesManagement