Maximo Aviation and Asset Configuration Manager - Build Data Interpreter (BDI) on the Maximo Application Suite

 View Only

Maximo Aviation and Asset Configuration Manager - Build Data Interpreter (BDI) on the Maximo Application Suite 

Fri March 17, 2023 07:11 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 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)

1       Introduction

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.

     

    2       System Architecture

    2.1     Overview

    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.

    2.2     Architecture Diagram

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

    3       BDI Status Dialog

    3.1     Overview

    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.

     

    3.1.1        Current Configuration

    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.

    3.1.2        Alternative Configuration

     

    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.

    3.1.3        BDI Actions

    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:

    4.2 BDI Configuration Settings

     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

    8.1     BDI Status and Problem Codes

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

     

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

    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.

      8.2     BDI Crontasks and Asynchronous jobs

      8.2.1    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

       

       

       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

        

      8.4     Troubleshooting

      8.4.1 Unable to connect to the BDI from the BDI Status dialog in Manage.

      Verify the BDI End Point definition in the BDI Queue Status application. 

      Ensure the SSL toggle box is checked and port is set to 9443.

       

       

       










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

      Statistics

      0 Favorited
      87 Views
      0 Files
      0 Shares
      0 Downloads