Assets and Infrastructure Management System (AIMS) Software
Best Practices Guide
Current as on 30th January 2004
Document #07
A good way to start is to first read the Frequently Asked Questions and the AIMS Glossary - these would give a good grounding for the User to understand the methods and practices described in this Guide.
The AIMS Software has been designed to be domain-independent. It can store hierarchical information about Assets (movable or immovable), which can retrieved for further use. However, there are some rule of thumb, which when followed, can help the User to make the best use of this Software.
This Guide explains these rules of thumb, from the perpective of a beginner. It tells about the following steps:
Types of Information
that can be Stored in AIMS Software
Collecting this Information
Studying this
Information to make a mental model
Fine-tuning the
Structure of this Information
Deciding on the Mode
(Local or Distributed Mode) to Use
Feeding this
Information
Using the AIMS
Software effectively
Tips for AIMS Administrators
Much of what has been discussed here, has been put into practice while writing the Getting Started Guide, the document which the User must read before using the AIMS Software.
Types of Information
that can be Stored in AIMS Software
AIMS Software has been designed to store hierarchical information about highly complex Assets. Assets can be movable (e.g., an aircraft carrier) or immovable (e.g., a nuclear power plant). A complex and important asset such as an aircraft carrier, will have a number of sub-systems, components and parts. These can be called the "hardware" of the asset. Each of these hardware will have a definite (and most probably, an hierarchical) relationship with each other. In addition, each hardware would have undergone certain evolution, e.g., design of the hardware, material selection for the hardware, its fabrication, commissioning, use, repair / replacement, and decommissioning. All this information and more can be stored in the AIMS Software. Th AIMS software also has provision to store links to various multimedia information about these hardware, such as signals, images, audios and videos. Such stored information can also be retrieved, viewed, copied, deleted, modified, moved, searched and acted upon by issuing timely alerts.
Collecting this
Information
Before embarking upon using the AIMS software for storing information about a particular asset, it is very essential to collect this information (atleast a reasonable chunk of this information; it is only natural that information will be keep growing; AIMS allows the asynchronous, incremental addition of information) in all its perspectives. A good source where this information can be collected is from the End User, who will access and employ this information for various business / technical purposes. Types of information that could be collected include facts, relationships, properties, lifecycles, physically measured values, numerical data, descriptions, serial numbers, links, photographs, audio and video information. While collecting information, the designer must consider the "information cost" (how much it costs to get that piece of information) and "information value" (the importance of the collected information, at present or in the future, for the "well being" of the asset).
Studying this
Information to make a Mental Model
This is the most important step, which will boost the effectiveness of using the AIMS Software. This step will also discover the ways in which the collected information must be cast into the AIMS database structure. It is essential to study the relationships between various pieces of information and uncover if there are any obvious (or hidden) hierarchical structure among them. While doing so, it is worthwhile to remember that in AIMS, the root of the database structure is an Asset. So, the first and foremost task is to find the root among the collected information. Each Asset can have any number of Systems. Each System can have any number of Components, and each Component, any number of Parts. These hardware (Assets, Systems, Components and Parts) each can have any number of evolutionary cycles (Evocycles) assigned to them, along with any number of Notes to add additional description and multimedia files.
Naming the hardware and the Notes & Evocycles is crucial for the success of the implementation. The designer must remember that, by design, the AIMS Software does not allow identical names to be present - this is not a limitation. For example, if four identical engines are present in an aircraft two on either side of the fuselage, they will be numbered as, say, R1,R2,L1 and L2. So, the turbines in these four engines can always be named as L1Turbine, L2Turbine and so on, even though the turbines are identical in every other aspect.
It would also help if a rough tree-like structure is drawn, based on the collected information, on a piece of paper and studied carefully for a certain amount of time. It is in this step that the designer will make a final decison whether (a) the information can be stored in AIMS Software at all and (b) the information collected in enough to make a beginning.
Fine-tuning the
Structure of this Information
Inspite of the relationships that are discovered in the previous step, it is quite natural that some information may not fit directly into the structure of the AIMS database. IT may then become necessary to fine-tune either the information itself, or its structure to make it fit, without any loss of information. In most cases, this would not be a problem, provided the previous step Studying this Information to make a Mental Model has received due diligence.
Developing a Notation
and Documentation
It would do a lot good in the long run, if the User, writes down the various notation that he/she uses while entering the data into the AIMS database. This very important from two perspectives (a) to be clear as which layer of information goes into AIMS as what type of hardware; for example, which object should be the Asset, which category of objects should be treated as Systems, whether regrouping of existing data is required to define a layer of data, what are relationships between these data layers, how are the Evocycles defines for this Asset, how to group the Stages, Properties, etc., what type of Units are used while entering Values to Properties/Sub-Properties, what currency is the default currency etc., and (b) to generate a clear documentation of the Asset and all its Children. Both (a) and (b) are essential, not merely for the User after a few months/years as a point of reference, but also for a new User who has not entered the original data in an existing / operating AIMS Software. Among other things, any re-casting of existing data for the sake of entering into the AIMS database and fine-tuning of the database itself, are potential candidates for documentation. It must be noted that every Asset (and all its Children) may require different form of re-casting and fine-tuning. There is no one-size-fits-all strategy, when it cames to effective database struturing / entry / usage. And then, it will evolve as the usage grows.
Deciding on the Mode
(Local or Distributed Mode) to Use
This is more of a performance and hardware issue to be decided upon. In the local mode, all the databases of AIMS Software (assets, systems,....,notes, signals,images, audios, videos, and all the multimedia files) reside in the local machine (localhost) where the AIMS Software itself is located. In the distributed mode, the databases are located in Computers (host Servers) other than the localhost, which are connected to the localhost through the same Intranet. If local mode is used, since the databases reside locally, a faster Computer would be required, one which has (a) a faster processor, (b) higher memory (RAM) and (c) a large persistent storage device (a big hard disk drive), depending upon the size of the databases. If distributed mode is used, the localhost could be a simple Pentium-class machine, having a fast-ethernet (or Gigabit ethernet) access to the Intranet.
Very small databases might be hosted in local mode. Large databases are best hosted in distributed mode. In addition, if multiple Users, wish to access a given information, the use of distributed mode is more appropriate. An extreme case of distributed mode is when each of the AIMS database file is loacted in an independent Server. This would provide maximum security, throughput and ease of data management (such as archiving, back-up etc.).
In both modes, the local host must run on either Windows 2000 or Windows XP Professional. In the case of distributed mode, the host Servers should preferably run Windows 2000 Server or Windows 2003 Server. Also, one can switch between these two modes, though it might turn out to be more cumbersome as the databases become larger in size and more distributed in nature.
Feeding this
Information
Once the root, and the data structure are identified, feeding of information into the AIMS Software can proceed at a convenient pace. This step requires the full understanding of two aspects: (a) How to Create a New Asset in AIMS? and (b) How to Add / Edit / Copy / Move information within the AIMS Software. AIMS also allows the deletion of unwanted information present in its database.
Using the AIMS
Software effectively
Some of the factors that needs attention are: (a) Choose the right mode of operation, based on User requirements and available hardware, (b) Constant updation of data to make sure the AIMS database always has the latest information, (c) Careful backing up of information to prevent data loss, (d) Use of actionable Trigger Alerts wherever required, so that none of the impending tasks are missed (e.g., recording a pressure reading, timely inspection of a hardware to meet regulatory requirements, etc.), (d) Recording the complete description of all the details pertaining to the hardware in various Notes and Description fields.
Tips for AIMS Administrators**
In a Security-sensitive environment, the AIMS Software Administrators broadly have TWO tasks cut out for them, to ensure that the AIMS databases and their security are not compromised. These two tasks are (a) Configuring the functionalities of the AIMS Software, and (b) Configuring the location of the AIMS Databases.
Configuring the AIMS
Software Functionalities
The first task of the AIMS Administrator is to ascertain if the AIMS Software will be used in an environment where Security is paramount. If so, the Administrator, preferably one who is also an Administrator of the Intranet Domain, should create three types of users, viz., Users, Managers and Administrators. Users normally have the least previleges, and the Administrators have all the previleges. Managers are somewhere in between.
AIMS has been designed to be used within the Windows 2000 or Windows 2003 Server environments, accessed from local machines (clients) which are either Windows 2000 Professional or Windows XP Professional.
The various functionalities (e.g., Creation of a Report) of the AIMS Software are configurable for Users and Managers. The AIMS Software can identify the Group (Users, Managers or Administrators) to which a User belongs, by referring to a Administrator-defined configuration file, that has only READ rights to others. Once the Group of a User is identified, the Software either allows that functionality to be present or not.
Configuring the AIMS
Software Database Locations
The second task which an Administrator should perform is to decide the Mode of AIMS Software operation - either local mode or distributed mode. If Security is a concern, the individual database files ("assets.dat", etc.) must be located in such directories (either locally or remotely) where authentication and authorisation are set and activated for the users of AIMS Software. For example, if Managers are not allowed to update a data fragment, the corresponding database must be located in a directory that has only READ rights for the Managers, and so on. Since AIMS uses a separate file for each database, in addition to the separate directory (or directories) for multimedia content, each of these being fully configurable, the Software provides sufficient granularity to practise a rich set of authentication and authorisation rules.
The Administrators should also take special care to protect the various *.ini files. They should also monitor the log file (aimslog.ini) for any suspicious activity. Proper and regular back-up of AIMS databases and configuration files are equally important.
**Not activated in the current version of AIMS Software
Last Updated on 30th January 2004