km5 Integrated Systems & Equipment List (ISEL) hri07e
1.0 Title: Integrated Systems & Equipment List (ISEL)
2.0 Purpose:
The km5 ISEL is the control document for all system and sub-system tags to the component level – which is the smallest item which will be tagged for identification prior to using the manufacturer’s bill of materials part number or consumable item sku.
3.0 Recommended Usage:
This is a fundamental document in the infosys2 knowledge management system and is mandatory in this context.
4.0 Frequency: The ISEL is created from the earliest baseline version of the project management plan (pm7) but from that point on should only receive updates from the plan and not be over-written automatically. It is essentially being continually updated – but should not be published more than once a week, better – once a month.
5.0 Reference Documents:
5.1 pm1 Work Breakdown Structure hri07e
6.0 Responsibility: The Senior Project Engineer is responsible for the overall accuracy of the list, but this does not override the responsibility of each Senior Engineer or Supervisor to produce an accurate list for the parts they control.
7.0 Ownership: The Project Owner owns the ISEL.
8.0 Level of Effort
The ISEL is very heavily front end loaded and can require as much as 50% of the total effort until the first sub-systems are identified – after which the effort should fall off rapidly to (1hr per resource per month??)
9.0 Risks
Parts which are incorrectly listed or missed in the ISEL will be incorrectly installed or missing in the end product. This could be minor (from the wrong door knob being used) to fatal (when the wrong beam is used). Informal replacement of the ISEL by private knowledge and lists is common – but this only increases the previous risk probability. (The severity of the result is not a function of which list was used, that is decided by physics or accounting.)
10.0 CONTENTS:
The ISEL contains:
10.1 the WBS no. (tradition maybe?)
10.2 the Tag no
10.3 the Tag label (i.e. the proper equipment label)
10.4 the link to the data sheet
10.5 the location of the item
10.6 the status of the item – one of:
“new” – since last publication
“approved”
“hold”
“obsolete”
“alternative **”
“ordered”
“<yad><yada><yada>
10.7 the effective date of the status
Design changes and tag number updates should be updated upon 1st draft and shown as “alternative” Most of the detail is found on the linked data sheet.
The procedure for updating the ISEL is found elsewhere. (see 5.0)
10.8 The ISEL Tree
A top down, vertical tree showing the parent/child systems-subsystems-modules-etc should also be generate-able at any point in time. The "completeness" or "dependability" of the individual components should be visualized by line weight, colour, background, indicator, flag or whatever to show the components that are unlikely to change versus the ones that are - and especially ones that were previous "solid" and that have been degraded by changes above or within the ISEL.
11.0 Data Typing
R1: Data Typing may be in one of the following the forms:
11.1 coded algebraic expressions (using key codes)
11.3 RDF statements
11.4 DITA expressed documents
12.0 File Handling Policy
12.1 Backup
This is a candidate file for daily backup.
12.2 Privacy
There is no personal information in an ISEL.
12.2 Security
The security of the ISEL is mostly a function of the chaos it can cause if is wrong as a result of carelessness or vandalism. HRI does not deal in military grade projects and the Data Sheet tags are normally insufficient to reveal much patent information. The list may be a business risk however.