General Tips for Effective AIMS Software Usage
Document #10
Current as on
Tip #0
The AIMS database is never built
in a day ! It will grow over a period of time, as and
when data comes in. As data entry progresses, there could be a need to copy or move data; or
to re-align, re-cast or even delete data! One good method is to create a mental
model of the proposed database structure and then think it over a period of
time - this could help in unclogging certain mental blocks and might lead to a
better perspective of the database structure. The AIMS database is so designed
to allow asynchronous (entering different data at different times) and
incremental (entering small fragments of data at a time) data entry.
Tip #1
Whenever you find two (or more)
identical components, which may share common data elements, it would save a lot
of time and effort, if data pertaining to one component is filled, and then
COPIED for the other components. This is a huge time saver, particularly when
large number of identical components shares the same data structure. In such
cases, the following points need special attention:
* Make sure that there are NO mistakes
in the first and original data structure - otherwise, these mistakes would be
copied for all the other components.
* Remember to RENAME the COPIED nodes,
so that they clearly reflect the type of component they represent.
Tip #2
If multiple teams enter data into
the same database (pertaining to the same asset and its branches, for example),
it would do a lot good if they agree apriori on the
notation and data structure to be followed. If this uniformity is not enforced
right from the beginning, even though the entered data would be syntactically
correct, it make not mean the same (to everyone)
semantically. Also, if the agreed notation and data structures are recorded
(even inside AIMS itself, as Notes) this would help someone in future who might
have to carry on forward, from an already generated database, or for someone
who tries to interpret / use the data in future.
Tip #3
While entering data, it would be
a good practice to watch the Identification Number (ID) automatically generated
by the AIMS Software - this is a read-only field. For example, if a new i.e.,
first sub-property is entered into a property, the ID should end with 'SP1',
for the second it should be 'SP2' and so on, otherwise something is amiss -
either the User's understanding or the AIMS Software's initial conditions. In
any case, consult the AIMS Software Administrator. However, the User must
clearly understand that the actual value of the ID has no bearing on the
performance of the AIMS Software. To be sure, the User may wish to validate the
database, once in a while.
Tip #4
This is inside information! While
storing Values of a property or a sub-property, the AIMS Software stores the
value internally as a 'LIST of STRINGS'. For example, if you store a length
value as 43.28 meters, the AIMS Software actually stores it as
["43.28","meters"] ! But, while
displaying this information to the User, it will show it as just 43.28 meters.
This variation in representation is actually an advantage, since one can store
a whole series of values, e.g., a signal having 1024 points for example, in
this manner and process that series as if it is a list! Additionally note that
if the user stores a value 43.28 meters, then both '43.28' and 'meters' are
stored as STRINGS, i.e., the floating point value of 43.28 is converted to a
STRING and stored.
Tip #5
While entering fresh data,
remember that some fields are compulsory - such as the Name and the
Description. The User may not be able to add fresh data without this basic
information. The Serial Number, the USI Number data fields are not mandatory.
While editing data, the 'Update' button will get enabled only if it senses
changes in these vital fields.
Tip #6
While casting available data into the structure of the AIMS database, ease of data storage, ease of data retrieval, and the importance of the data are points to be considered while allocating their "position" within the data structure. For example, in the 'Shuttle Transport System Example Database', the Orbiter System has been divided into three components the forward fuselage, the mid-fuselage and the aft-fuselage. In this representation, the crew cabin becomes a part of the forward fuselage component; still, in view of the importance the crew cabin, it has been assigned the status of a 'system', which is perfectly OK as along as the entire team agrees on this aspect and properly document it. Also, at times it may become necessary to add the same, identical data in two different places, just for the sake of increased clarity (and document it).
Last Updated on 9th February 2004