3.1 Method The method for formalising the use and meaning of terms used in schedules can be summarised as follows: -Select appropriate sources of terminology -Where similar terms exist for the same item or concept, select the clearest, least ambiguous one. -Where different definitions are found for the same term, select the one from the most authoritative source. -Where a definition for a term does not exist, carefully draft one. Seek consensus on the definition where possible before finalising it. -Examine selected terms and definitions for potential ambiguities, and adjust as necessary to minimise them. -Document and disseminate glossaries of defined terms to users.

3.2 Sources of terminology When formalising the meaning of terms used in a schedule give preference to defined terms from sources with regulatory and legal standing. It is important that terms selected do not contradict or blur the meaning of terms used in documents like the Building Code of Australia (BCA) or standards cited in the specification. If choosing between alternative definitions of a term, give preference to the listed sources in the following order: 1.BCA. 2.Australian Standards and Handbooks. 3.Appropriate international and national standards. 4.Terminology, abbreviations and codes used by major client groups. 5.Publications by professional and government organisations. 6.Publications by trade organisations. 7.Publications by manufacturers’ organisations. 8.Product technical literature. 9.Established and accepted industry usage. Use terms derived from well established, industry endorsed publications that have been peer-reviewed. Many make a point of defining the terms applicable to their subject matter, so they are a good source of terminology. Only use proprietary terms or brand names when specifically nominating a proprietary item to be used.

3.3 Definitions 1.Where necessary, provide definitions adjacent to the schedule to eliminate ambiguity, e.g. define ‘width’ so that it is clear whether it refers to a nominal width, an overall width or opening width. 2.Identify the source of definitions. If there are a lot of definitions, or they are of a complex or specialised nature, it may be more appropriate to omit the definitions and refer directly to the source document, e.g. ‘Refer to AS 4145.1 for definitions of terms used in this schedule.’ 3.Add qualifying adjectives or pronouns to terms, e.g. panel width, opening width if it will reduce the risk of misinterpretation.

3.4 Schedule elements 1.Title: Follow the naming conventions adopted for the class of objects scheduled. 2.Identifiers: Keep identification codes short – one, two or three letters plus the minimum number of digits that will accommodate the number of items likely to be scheduled. (one digit – 9 items, two digits – 99 items, and so on). 3.Make identification codes as self-evident and intuitive as possible to aid recognition. 4.Provide a legend on any document in which identification codes appear.

3.5Example – Using a glossary to establish consistent terminology

Glossary of terms for properties Table 1 on the following pages is an example of the sort of document that can be used to record the names and definitions of headings (i.e. properties) to be included in a schedule – in this instance a door schedule. It is an example of one of many that could be created for this purpose. In addition to acting as a glossary, it also prescribes the format of values associated with each property. The list of properties is not exhaustive – they have been extracted from a parent list of door and door hardware properties. See Appendix A for the parent lists. The subset of properties chosen from the parent list would vary with each project. For example, a door schedule for a house will require a simpler set of properties than one for a hospital.

Document purpose This sort of document is intended to be used as a template for anyone creating or using model content - in this instance, doors. As a common reference it would facilitate a consistent approach by all modellers. Some of its content might appear self-evident and unremarkable. 'Frame material', for example, would not appear to require a definition. The most significant thing about it is the principles it embodies, which are: -Derivation of terms and definitions from established, credible sources such as the BCA and Australian Standards. This approach does not have to be applied rigidly - there can be instances where alternatives are more appropriate. A table like this is the ideal place to document any divergences and explain the reasons, if required. -Identification of the preferred term to be adopted from among a number of options. In everyday conversation the terms 'door', 'door panel' and 'door leaf' might all be used interchangeably and still be understood to be referring to the same thing, but the use of terms in a BIM context demands less ambiguity. -Definition of how an item is to be measured for the purpose of describing its size in a consistent manner. Again, 'door width' could easily be interpreted as referring to the width of the door leaf, the clear door opening width of the door frame, the overall dimension of the door frame, or the rough opening width. The document acts to say: "of all these alternatives, we will adopt 'leaf width' as the primary measure of door width." This does not preclude the use of other measures such as rough opening width, if required - they just need to be defined clearly as well and used consistently. -A statement of the required values for properties and/or the provision of examples of acceptable value formats. Even if the meaning of a property description is likely to be readily understood without much explanation, the potential always exists that different people will enter values for them in a variety of formats or units. -The order properties are listed. That is: (1) Identification/Doorset (properties of the assembly as a whole), then (2) Door leaf (primary component), then (3) Door frame (secondary component), then (4) Door hardware (ancillary components). -Definition of the scope and level of detail of information that is expected. The table can be used to clarify, for example, whether the information required for a particular schedule entry is either 'yes' (present) or 'no' (not present), a brief description of type, a product code, or a detailed description of type, material, finish, colour, etc.

Sources of terms and definitions used in Table 1 AS 4145.1-2008 Locksets and hardware for doors and windows – Part 1: Glossary of terms and rating system.Building Code of Australia. SAA HB 50-2004 Glossary of Building Terms.

Table 1 Schedule properties – definitions and required values

Figure 1 Spatial frames of reference

A viewer-centric frame of reference has been adopted for the orientation-based schema because of its flexibility. Cartesian or geographic references would have to be defined for each individual building and the descriptors for each object (even identical ones) would vary, depending on their orientation relative to the absolute frame of reference. With a viewer-centric reference, once an object's orientation has been defined by how it is viewed, approached or used, the descriptors remain fixed and consistent regardless of where it is installed or how it is aligned geographically. The appropriateness of this frame of reference is not that surprising considering buildings are primarily for use by people.

Possible approaches to formulating a set of conventions Possible approaches include: -Single schema: Adopting one schema as the basis for a set of descriptor conventions and applying it rigidly with few exceptions would seem to offer the advantage of consistency. Applying it to all types of objects, however, has its problems. An orientation-based schema would be difficult to apply to unfixed materials because their final installed orientation cannot be known. Applying an orientation-based schema to all installed elements could result in some counter-intuitive results - for example, if Depth is assigned to front-to rear dimensions relative to the viewer it would then be used to describe the thickness of a wall or door leaf. -Notation system: Adding a qualifying notation to common descriptors would remove any ambiguity from terms like width and depth. For example, DI for Depth (Inferior) indicating depth in a vertical downwards direction, and DA for Depth (Anterior) indicating depth in a horizontal front-to-rear direction (relative to the user or viewer. While this seems to eliminate a significant amount of ambiguity, problems could be anticipated having it widely accepted, implemented and understood by everyone in the construction industry. -A hybrid proportion-based/orientation-based schema in which both schema, and associated descriptors, are applied, depending on context.

Proposed conventions Conventions based on a single schema or a notation system have been discarded because of their limitations. The proposed conventions are based on a hybrid schema. This accommodates the large variety of objects found in buildings and their surrounds. The principles proposed can be summarised as follows: For unfixed materials, use a proportion-based schema: 1.Use length, width and depth for cuboidal forms. 2.Use length, width and thickness for linear or planar forms. For installed (or ready to install) elements, use a mixed orientation-based/proportion-based schema: 1.Use height, width and depth for cuboidal forms. 2.Use height, length and thickness for vertical planar forms. 3.Use width, length and thickness for horizontal planar forms. Note: The difference between cuboidal forms and planar forms would need to be defined by an agreed aspect ratio. While the hybrid schema proposed might initially appear complicated, it would probably be easy to use in practice because it formalises many of the syntactic rules already internalised by the general population. Descriptor listing order in text (schedules, etc): As a general rule, list the descriptor for the smallest dimension first and that for largest or vertical dimension last. The following tables (with corresponding illustrations below) show four common classes of building objects, and explains the conventions applicable to each in detail

Adoption of an underlying conceptual framework can be helpful when formalising the listing order of headings (i.e. properties) in schedules but rigid application of such a framework may not always produce the best result – it has to be tempered by considerations of what will be most useful. Always apply the test: What will be the effect of this arrangement on the user when the schedule is used for typical, routine tasks? In a BIM environment it is generally better to break properties down into their smallest subdivisions rather than combining them, e.g. placing the manufacturer’s name and product description in separate columns is better than placing both in one. Because BIM schedules are managed by a database and have spreadsheet-like functionality, the data in each column can be sorted as required. Subdividing properties increases specificity when searching and sorting data. The larger and more complex the project, the more this principle applies.

1.Place identifiers before subclass descriptions, and subclass descriptions before properties.

2.Place alphanumeric codes or tags before the item's title to assist sorting and referencing.

3.Place subclass or subtype descriptions of the class of items being scheduled before properties. The subtype can be defined by a number of criteria including form, function, operation and power source, e.g. sliding, casement, awning, double-hung windows. The subtype directly influences the following property set. Placing the subtype early in the order allows the properties to be tailored to the subtype instead of having to provide a more universal set of properties to accommodate a wider range of possibilities. This usually requires some consideration of the range of possible subtypes that may be needed and establishing naming conventions for them prior to implementing them. This consideration is likely to be required at some stage anyhow, regardless of where the subtype description is placed in the schedule order.

4.Place properties that are usually decided earlier in the design process before properties that are decided later, e.g. door handing before panel type and finishes.

5.Place general properties before special properties.

6.Place salient properties before detailed properties.

7.Place more common or frequently used class properties before less common or infrequently used class properties. This means that when items are compiled in the schedule, entries appear more homogenous on the left, and become increasingly varied as they move to the right. This gradation makes locating similarities and differences between items an easier task.

8.Place properties associated with an assembly as a whole before properties of its components.

9.Place properties associated with the primary or essential components of an assembly before ancillary or optional components. Order the properties for each component in turn.

10.Schedule the components of an assembly in general order of assembly or placement, e.g. framing before lining, substrate before finish, or consistently apply another principle noted in Part B,3 Information ordering. Then list the properties associated with each component in the order recommended above.

The general principles above have been applied in the formulation of following recommendations for ordering properties:

Identifiers 1. ID code – instance. A code for identifying an individual item, e.g. each window. 2. ID code – type. A code for identifying a particular type of item, e.g. each partition type. 3. Name. A brief identifying label or short description, e.g. room name. 4. Location. This function may be filled by location-based names like room names. If the location is identified by a room name, for example, use the location field to identify a more specific location within the room, e.g. north wall, ceiling, floor, above ceiling.

Descriptors - generic 5. Description. A brief statement that gives the reader a clear picture of an item. Its main function is explanatory. For example, to describe a product identified by product number only that would otherwise be meaningless to the reader. Beware of duplicating the individual properties following. If its content is fully described by other properties and does not add value (by reducing ambiguity, etc), omit it. The name (Item 3), which is often a short description of an item, may be adequate. 6. Type. A significant subtype of the class of items being scheduled, e.g. for a window schedule: sliding, casement, awning, double-hung. See the notes under Part B, 3 Information ordering. It can take the form of a written description or a code that can be interpreted by means of an associated legend. Manufacturer: Insert the manufacturer’s name. If it is not known, or the project is being documented on a non-proprietary, performance basis, insert ‘Generic”.

Descriptors - proprietary Insert the following fields if a proprietary method of specifying items is being used: 7. Manufacturer 8. Product name. 9. Product range or series. 10. Product reference number. 11. Product supplier name and contact details. 12 Product image. 13. Product data sheet. Incorporate a pdf file or hyperlink. Other options include a pdf file or hyperlink to material safety data sheets (MSDS) and installation, operation, cleaning and maintenance instructions. The inclusion of these items will depend on the intended recipients of the schedule, the capabilities of the modelling application and considerations such as the size of the resulting file. Depending on the approach to documentation for the project, detailed product data is generally better located in the specification.

Properties 14. Properties – dimensional. Width, Height, Depth. Define the basis of measurement if it is unclear how these should be measured. Include the unit of measurement in the heading within brackets, e.g. (mm). 15. Properties – physical and/or visual. Material, finish, colour, pattern. Can also include physical configuration: hinged, sliding, etc. 16. Properties – rated performance. E.g. fire rating, acoustic rating, IP rating, slip resistance, durability class. Although related to 'Properties - physical performance', rated performance is based on a prescribed regime of measurements and/or tests rather than direct simple measurement. They have been placed before 'Properties - physical performance' because they often provide a better overall indicator of performance in practice and/or as installed. For example, place a WERS rating for a window before individual R-values for its glazing and frame. Likewise, the total R-value of the window frame gives a broader indicator of performance than the thermal conductivity properties of its constituent materials. Note: Precedence does not imply importance. The thermal conductivity properties of the constituent materials may be necessary for thermal analysis. Make sure that values entered for rated performance do not contradict those entered for physical performance. Omitting one or the other may be necessary to eliminate this possibility. Include the rating criteria in the heading. 17. Properties – physical performance. Intrinsically associated with, and relevant to the material properties of the item being scheduled, e.g. voltage, flow rate, cooling capacity, light output. These properties can be directly measured or tested and expressed as simple relationships between units of measurement, e.g. kg/m2. Include the unit of measurement in the heading within brackets, e.g. (kW/hr). 18. Properties - rating scheme score. The item's performance expressed as a dimensionless figure, point score or performance category based on a rating scheme, and representing an assessment based on wide range of criteria, e.g. Green Star. They have parallels to 'Properties - rated performance' but differ in that they are more global and relate to an assessment of the project as a whole, rather than properties of individual items. In projects subject to a rating scheme it might be more appropriate to link some items using 'Sorting references'. Include the rating scheme and rating category in the heading.

Referencing 19. Sorting references codes. These are notations or codes used to sort or filter scheduled items for some purpose – sometimes called assembly codes. They can be from an established classification system for sorting the scheduled items into that system’s order, e.g. NATSPEC codes for sorting items into specification worksection groups or Australian Cost Management Manual (ACMM) notations for grouping building elements and sub-elements in cost plans. Include the name of the classification scheme in the heading. Other types of codes used to sort items in a global manner include provision codes for identifying who is responsible for the supply and installation of items in a project. For example, Group numbers used by health authorities: Group 1: Provided and installed by the builder, Group 2: Provided by the client and installed by the builder, Group 3: Provided and installed by the client. Similar codes can be used to identify which items are to be relocated, reused, recycled or disposed of. Provide a legend for interpreting codes unique to the project. Sorting codes can also be used for administration or display purposes. One code can be used to indicate/sort items that are to be displayed in documents, and another to indicate items that have to be checked before their display is authorised. See notes on Administrative notes. 20. Documentation cross references. These are used to indicate locations where the scheduled item is referred to elsewhere in the documents. They are navigation aids to help users find the information they need, e.g. drawing numbers, detail drawing numbers, specification worksection numbers.

Quantities and costing 21. Quantities. Can be a single field to show the total quantity of an item or a series of fields for calculation purposes, e.g. unit, quantity, rate, amount. Set up sum (totalling) fields to calculate quantities in the desired format, e.g. for all items, or for subsets of items. The format of the schedule (e.g. ‘every instance itemised’) will often determine this. Append any conditions, qualifications or assumptions associated with measurement, as appropriate. 22. Costing. Can be a single field to show the total cost of an item or a series of fields for calculation purposes, e.g. unit, quantity, rate, amount. Incorporate the currency symbol adjacent each total amount or in the heading within brackets, e.g. ($A). Append any conditions, qualifications or assumptions associated with costing, as appropriate. Include notes about when costing is to be displayed or hidden. Quantity and costing fields can be combined if preferred.

Comments 23. Comments, remarks. Notes on any issue relevant to the item, e.g. any variation to an otherwise standard property, special requirements, installation details. This field can act as a ‘catch all’ for any matter deemed significant. It should be made clear which notes are intended for general distribution, e.g. the client and other consultants, and those which are intended for reference by the authors of the schedule only (for reminders, quality control, etc). See Administrative notes below. The distinction can be made clear by means of notes or graphic devices like heavier dividing lines between cells or applied tones.

Administrative notes Use the following fields to indicate the status of a schedule item with regard to approvals, authorisations or program. They are generally applied to the schedule as a whole – in which case they appear outside schedule in the title block, footer, etc, but are sometimes applied to each scheduled item when this degree of tracking is required. Amendments to the previous issue of the schedule should be clearly indicated by devices such as revision clouds, coloured text or applied tones – they are easily missed if this is not done. 24. Revision number. To office numbering system. 25. Issue date. Nominate format used by office: DD/MM/YYYY, DD.MM.YYYY, YYYYMMDD, etc, 26. Notes (administrative). e.g. schedule items are to be displayed or hidden such as costings and approvals. 27. Status. Preliminary, for tender, for construction, etc 28. Approved by. Name or initials with legend. 29. Checked by. Name or initials with legend.

Information flows over the duration of the project must be analysed before protocols for exchanging data between members of the project team can be formalised. The information requirements of each party at each stage need to be analysed and agreed. Guidance on formulating frameworks for data exchange throughout a project is beyond the scope of this report – it is more concerned with the principles applied to finer scale exchanges within such a framework. Documents that provide guidance on such frameworks - often referred to as Model Progression Specifications (MPS) - include Integrated Project delivery: A Guide published by the Californian division of AIA. Contractual documents used to formalise the responsibilities of project team members regarding data exchange have been developed for this purpose and include the AIA Document E202 BIM Protocol Exhibit – 2008.

The following schedules and commentaries illustrate the principles outlined in Part B 4 Using schedules for data exchange. Schedules for two different types of items are featured – fans and door hardware.

A door hardware selection schedule like Schedule 1 can be adequate for tendering purposes, but a schedule inventory summary like Schedule 3 will provide more accurate pricing. A door-by-door hardware schedule like Schedule 2 is essential for construction purposes. Although a simple example, this series of schedules illustrates how schedules can be used as a briefing instrument and a medium for the exchange of information between different parties. It also illustrates how different subsets of information can be extracted from available information and formatted to suit the needs of different users at various stages of the project.

1 BASICS

HB 50 defines Schedule (items) as: -‘Tabulated information on a range of similar items in a project which differ in detail, such as door schedule, window schedule, etc.’ This is the meaning ascribed to the term for this project, as distinct from a timetable or program.

Schedules usually function to collect detailed – usually written – information about multiple instances of similar items in a compact format. They often provide an extract of detailed information useful to a specific group of users. For example, a door schedule provides a consolidated summary of the details of all doors in a project that can be used by a door manufacturer to assemble an order. Schedules can also be used to gather together information that is scattered throughout a set of documents to provide a co-ordinating overview of that information, e.g. Finishes, Fixtures and Equipment schedules that summarise these items on a room-by-room basis. Sometimes schedules are used as a tool to co-ordinate documents themselves rather than the items documented.

Property-value pairs The fundamental relationship embodied in a schedule for a class of items is: Item – Property – Value That is, an item can be characterised by a class to which it belongs and a set of property-value pairs. A synonymous term for item is object – particularly when used in the context of BIM – where many of the items being scheduled are model ‘objects’. A schedule, by definition, includes more than one item. Most schedules include more than one property for each item.

Properties and attributes The terms property, characteristic, attribute and parameter are often used interchangeably and rather loosely. They can be strictly defined, particularly in the domain of computer programming, but the definitions vary with programming language and methodology. In the interests of consistency this document has adopted the definitions for attribute and property given in ISO/IEC Guide 77-1:2008. This Guide covers topics such as data exchange for product/object libraries, and references standards associated with IFC and IFD, and the EXPRESS modelling language used for both.

Definitions from ISO/IEC Guide 77:2008 Attribute: Data element for the computer-sensible description of a property, a relation or a class. Note: An attribute describes only one single detail of a property, of a class or of a relation. Example: The name of a property, the code of a class, the measure unit in which values of a property are provided are examples of an attribute. Property: A defined parameter suitable for the description and differentiation of products. Note 1: A property describes one aspect of a given object. Note 2: A property is defined by the totality of its associated attributes.

Title The schedule title identifies the class of item that is scheduled, e.g. door. Schedules can be used to describe one type of item, e.g. door, fan, pump, or multiple types, e.g. finishes. What is scheduled and the format this scheduling takes is best determined by what will be most useful to the intended users. For BIM derived schedules the name and content will be derived from the objects scheduled.

Identifiers Items in schedules are identified by name and/or abbreviated notations (usually alphanumeric). Even though an item may have properties identical to other items, the identifier delineates it as a unique instance of that item type, separate and distinct from all others. An abbreviated identifier, or ‘tag’, has the advantage of not requiring the item’s name to be written in full each time it is referred to, and a short tag can be attached to individual items on a drawing without taking up much drawing space or obscuring other drawn elements. Including an item’s tag in a schedule and on drawings facilitates the co-ordination of both.

Grid Schedules are laid out in a tabular, or gridded, format with items listed along one axis and properties along the other. (For the purposes of describing schedules in this guide the arrangement of listing items vertically in the left hand column and properties horizontally along the top row has been assumed, although in practice this format can be reversed as required.) The value for each property of an item is placed in the cell located at the intersection of the ‘item’ row with the ‘property’ column. The gridded format makes it very easy to cross-reference information and to compare the differences and similarities between each item. The grid is not always drawn – it is sometimes implied by the layout of text or images.

Ancillaries Useful ancillary elements – placed outside the schedule – include: -A set of definitions for the terms used in the schedule. The source of terminology or formatting used for the schedule, i.e. reference documents, can also be identified here. -A legend or explanatory table to assist the interpretation of abbreviations, codes, tags or other conventions used in the schedule. -Notes on generalities which describe properties common to all items scheduled, e.g. all items are by the same manufacturer, or have the same finish. This saves having to repeat the same information for every item. The convention of writing ‘UNO.’ (unless noted otherwise) is an expression of this concept. (By identifying the similarity of all items in one place, the differences between items are highlighted in the body of the schedule. -Cross-references to the specification worksections or drawings relevant to the content of the schedule, or on which the schedule relies. -A comments or remarks column or row which allows qualifying notes to be made about a particular item, special arrangements applicable to an item, or to describe another property not shared with other items.

Compactness Schedules allow similar information about a chosen class of items to be displayed in a condensed form that facilitates locating and comparing that information. It makes it easier to locate and check information when creating, editing or using a schedule. The convention of relating a column or row heading to each cell in the same column or row produces a very compact format. It is the framework provided by a gridded format that makes it easier to compare the differences and similarities between each item than if the same information was provided in a single body of text.

Co-ordination By identifying each item with a unique code in a schedule and on the drawings (and/or the model) information in both documents can be accurately co-ordinated. This device is particularly useful for maintaining the integrity of information during the inevitable amendments that occur during the design development and construction processes.

Data exchange Because information attached to objects in a digital model can be exported as a spreadsheet or database file, and information in a spreadsheet or database file can be imported into a model to update it, schedules, which follow the same tabulated format of these files, offer a unique means of data exchange. This means information in the model can be extracted in a format readily accessible to users without them having to operate or understand a BIM application. A spreadsheet/ database/ schedule can be used for data entry or revision by non modellers and imported back into the model to update it.

Not all information is appropriate for display in a schedule. Significant amounts of specification text such as statements on quality, workmanship and procedures are not readily accommodated in schedules. They are general statements that apply to the project or sections of work as a whole, so the value of a schedule – the display of a range of similar items – is lost for this purpose.

Tabular Comprised of largely written information contained within the cells of a rectangular grid. Headings in the top row and side column of the table assist the identification and comparison of information about each item scheduled.

Drawn Comprised of a graphic representation (plan, elevation, etc) of a group of similar items. For example, an elevation of each type of window in a project is drawn as a group. They are generally shown as stand-alone components without adjacent wall finishes. A drawn window schedule represents a visual inventory of each type and number of window to be included in the project. A window number for each window in the drawn schedule and a corresponding number tag on the general arrangement drawings allows of each window to be located in the project. The inclusion of reference symbols at head, sill and jambs allows the construction details at each of these locations to be cross-referenced to the relevant detail drawing.

Hybrid A combination of tabular and drawn. Images and graphics can be included within the cells of tabular schedules or tabular information following a consistent format can be associated with drawn schedules. Room data sheets often combine tabulated and drawn information. This document is concerned with forms that are predominantly tabular.

Instance schedules Schedule every instance of a specific class of item. The are generally used for scheduling clearly defined, discrete components or proprietary products that are brought to site as pre-manufactured items and installed, e,g, windows, luminaires, sanitary fixtures, chillers. The total number of individual items is included in the schedule. Each scheduled item has a corresponding tagged item displayed in the model and shown on the drawings.

Type schedules Schedule every type or subtype included in a class of item, but not every instance of that type. The are generally used for scheduling major elements of composite construction that is usually constructed on site, e,g, roofs, walls, partitions, ceilings, floors, finishes. Because they form larger scale, continuous elements, it is often difficult to subdivide them into separate meaningful parts for the purpose of scheduling. This type of schedule often functions as a legend that shows the details of an item type tagged in the model or on the drawings.

Single class (or category) schedules Schedule a single class of item. Examples of these include window and sanitary fixture schedules. They are useful if a large number of items from a given class have to be scheduled. Because all items belong to the same class they usually share a smaller property set than multi-class schedules which have to accommodate the range of properties spanning different classes of items.

Multi-class (or category) schedules Schedule a number of classes of item. Examples of these include fixture, furniture and equipment schedules and finishes schedules that show the different finishes used on every surface of a project. They consolidate information that might otherwise be scattered throughout a number of documents and are useful for providing a comprehensive and co-ordinated overviews of a project. Because of their wide scope, they often make extensive use of coding which needs to be interpreted via associated legends. In this sense, the large bulk of information is handled by breaking it into a series of nested schedules.

Schedules need to be considered as part of the initial information and documentation planning of a project. Planning considerations can be summarised under the following headings:

Appropriateness Is a schedule the most appropriate means of describing a group of items? If most items in the group are the same except for a small number of variations, it may be simpler and clearer to specify the group by common properties and note individual differences, rather than creating a schedule. If this approach is taken, information should be laid out in a way that facilitates quick and accurate reference using devices such as headings, subheadings and lists. The brevity of the schedule format is not appropriate for all text-based information. Items requiring fuller description or explanation are better documented in a specification format.

Project scale and complexity The total number of items to be scheduled and the number identifiable groups (classes) of items will influence the appropriate number, subdivision and organisation of schedules. Previous projects of a similar type are often the best guide.

Project procurement method The number and type of properties that will be needed to be described for each item will be determined by project specification and procurement methods. If items are specified on a proprietary basis, the details contained in the schedules will be quite different than if they are specified by performance, e.g. as found in a design and construct contract. In the first case, a manufacturer’s name and product number may suffice. In the second, a whole set of properties will probably be needed to adequately describe its required qualities.

Location The intended location of schedules within the documentation set influences overall document planning and cross-referencing. Locations for schedules include: -Drawings. -Specifications: Located either within the relevant worksection and/or collected in an appendix. -As a stand-alone compilation of schedules.

Organisation Common methods of organising schedules include grouping them by: -Discipline (architectural, structural, services). -Project zones. -Building spaces. -Building elements, items or BIM object.

Format The ratio of number of items scheduled versus number of associated properties will often determine the format, e.g. portrait or landscape. The standard sheet size selected for the project influences the size of schedules, and if schedules need to be subdivided to fit.

Subdivision Analyse the scope of items to be scheduled and the extent of variations. If there are a large number of items scheduled, but they are comprised of a limited number of identifiable groups with shared properties, one approach can be to designate a notation or code to each shared property set and provide a legend for interpreting the codes adjacent the schedule. For example, if it becomes clear that there are only half a dozen typical ‘sets’ of finishes applicable to rooms in the project, it might be more effective to designate each set with a code and schedule this adjacent each room, rather than exhaustively identifying every finish on each ceiling, floor and wall. In these instances, legends effectively become sub-schedules ‘nested’ in the main schedule. Sometimes the extent of commonality/variance is not clear early in the project and this device cannot realistically be deployed until the design has reached greater maturity.

Amendments If a large number of document revisions are anticipated during construction, amendment and distribution processes can be simplified by breaking large schedules into single page schedules of properties for each item, e.g. one door per A4 sheet.

Layout and legibility Layout will affect the legibility of large schedules containing lots of text. Adjust font sizes and the proportions of cells so that their contents are displayed without crowding or fragmentation, e.g. avoid long columns of text with only a couple of words per line. Adjust the line weight of gridlines so that they are legible, but do not dominate the text. Vary line weights to group items and properties into logical subdivisions. A light tone applied to every second row can help avoid the misreading of information in cells.

Pattern recognition is a key aspect of human cognition – organising information using a pattern or underlying schema assists comprehension and retrieval by its users. Common principles for organising/ordering construction information can be summarised under the following headings (Note: Some of these schemas form the basis for the scheduling order set out in Part A, 4.3 Recommended scheduling order.)

Spatial Location: By building, by building space (zone, room), by relation to building envelope (internal, external, etc), by relation to other building elements (in or on another element). Physical/spatial proximity: From close to remote. Scale: From large to small.

Chronological Sequential – by order of consideration during design process: -Function – space – enclosure – element. -Form – construction type – material – finish type – texture/colour/pattern. Sequential – by approval process order: -Briefing – feasibility – pre-DA – Development Approval – Construction Certificate – Occupation Certificate. Sequential – by construction order: Determines dependency of one element to another, i.e. what has to be in place before another element can be fixed, installed, finished, completed or tested. Relates to concepts of significance and scale. Sequential – by operational activity: Replacement, repair, maintenance, monitoring. All of the above influence the generality-specificity and level of detail of information associated with scheduled items.

Conceptual Generality: From general to specific. Physicality: From abstract/intangible to concrete/tangible. Complexity: From simple to complex. Building type: By use or BCA classification. Element type: By element or object class – usually function based. Element significance: Primary, secondary or tertiary. Element function: Load bearing, non load bearing, decorative, etc. Performance criteria/properties: Structural, thermal, acoustic, fire, BCA requirements, ESD, LCA and OH & S considerations, rating scheme. Prescription method: Generic or proprietary product. Discipline (group responsible for design and documentation): Architecture, structure, services, civil, landscape, etc. Information user group: Client, contractor, subcontractor, supplier, building owner, building manager, tenant. Alphabetical: Useful for ordering items when no other classifying principle is obvious.

BIM applications organise modelled objects by their spatial relationships and an internal classification system. A fundamental concept of object oriented programming, of which modelling applications are an example, is that objects belong to ‘classes’. Each class shares a number of common properties or parameters whose values are varied to create a wide range of subtypes – producing ‘families’ or ‘libraries’ of parametric objects. This has the advantage that many common building elements can be modelled as variants of a few archetypes, instead of modelled every element from scratch. This means BIM objects are already organised spatially and by a predefined classification system when a schedule is created from a modelling application – a door schedule is a report on all objects from the class ‘door’ located in the model. Ordering schedule properties by classification ordering principles fits well with the way modelling applications are organised.

Traditionally schedules have been reports or static summaries of information used largely for contract documentation purposes. Digital modelling applications allow schedules to be used in a much more dynamic way – for viewing the data content of a model in a format tailored to the needs of the user, and as a medium for two-way data exchange – data entered into them can be used to update the model. If schedules are seen as windows into the information content of models, and as data entry interfaces, it opens up a whole range of potential uses not available to traditional paper-based schedules including: -Briefing instruments to ensure requirements (client brief, BCA, GBCA rating schemes, etc) are incorporated in the design. Schedules can be used to report on the design’s compliance with these requirements – conditional formatting can alert the designer to non-compliant items. This use is not confined to passing briefing information from client to team or from one discipline to another. For example, someone can create a schedule that describes performance requirements for different building elements and pass it on to someone else in their office to insert specific proprietary products that satisfy these requirements. See examples of this approach in Part A, 5 Principles - protocols. -Quality assurance documents such as project documentation templates, checklists and data entry control forms. The next two items are subclasses of these. -Workflow management tools for project teams to co-ordinate the input and exchange of data, e.g. Model Progression Specifications which form the basis of contractual agreements such as the AIA Document E202-2008 BIM Protocol Exhibit. This document establishes the protocols for the development of the digital model over the duration of the project. It provides a means of documenting how authority and responsibility for the development of each model element is to be assigned to team members at each stage of the project. -Templates for manufacturers creating digital objects of their products for downloading and incorporating in digital models. The template would include standardised parameters/properties, naming conventions, etc representing best practice as agreed by the construction industry.

Bednick, J. (2008) Organising the Development of a Building Information Model.

Sidawi, R. (2010) BIM schedules: Information-rich resources.NATSPEC BIM Scheduling guidelines © 31 December 2010

AIA (Californian division) (2008) Integrated Project delivery

AIA (2008) E202 BIM Protocol Exhibit – 2008

AIQS (2003) Australian Cost Management Manual

Bednick, J. (2008) Organising the Development of a Building Information Model.

Sidawi, R. (2010) BIM schedules: Information-rich resources

AS/NZS 1668.1:1998 The use of ventilation and airconditioning in buildings – Part 1: Fire and smoke control in multi-compartment buildings

AS 4145.1-2008 Locksets and hardware for doors and windows – Part 1: Glossary of terms and rating system

AS 4429-1999 Methods of test and rating requirements for smoke-spill fans

SAA HB 50-2004 Glossary of Building Terms

Building Code of Australia

ISO/IEC Guide 77-1:2008 Guide for specification of product properties and classes – Part 1: Technical principles and guidance

ISO 12006-2: 2001 Organization of information about Construction Works – Part 2: Framework for Classification of Information

These lists were compiled from a number of existing door and door hardware schedules from a number of different sources. Where similar terms were used to describe the same property, the term aligned with the BCA or Australian standards, or the most representative of common industry usage, or the clearest was adopted. Terms have been grouped by item to assist reference. These lists are not exhaustive - there are endless types and variants of door hardware, for example.

Identification Viewing panels Door number VP per leaf Level VP size - rectangular: H x W Room number VP size - circular: Diameter Room name VP glazing bead type (HS or SP) Location VP glazing bead material VP glazing type Structural opening VP glazing material Structural opening height Structural opening width Ventilation grilles Wall thickness VG size H X W Frame clearance - head VG type Frame clearance - jambs VG model number Head detail VG material Jamb detail VG finish Sill detail VG colour Doorset details Door frame Internal/external Overall door frame height Single/ pair/ multiple Overall door frame width Number of leafs Overall door frame depth Functional description Door frame reveal width Operation Door frame reveal height Handing and swing Frame thickness Leaf opens first Frame type Door type Frame material Fire resistance level Frame section Acoustic rating Frame rebate depth Radiation shielding Planted stop size H x W Radio Frequency (RF) shielding Frame wall thickness Escape width Transom section Security rating Sill section NATSPEC reference Frame detail Frame finish Door leaf/s Frame colour Leaf height Intumescent strip to frame Leaf width Fire seals Second leaf width Smoke seals Leaf thickness Acoustic seals Leaf undercut Mortar guards Rebated meeting stile Architraves Meeting stile rebate size Arch. Both sides Intumescent strip to meeting stile Head clearance Overpanel height Jamb clearance Overpanel construction Threshold gap/Sill clearance Rebated overpanel Fire rating certification plates Overpanel rebate size Leaf construction Leaf core material Leaf facing laminate, veneer or cladding Leaf edge finish Leaf lipping style (exp or over) Leaf lipping material Leaf finish Finish colour Fire rating certification plates

Identification Push button lock access control Door seals Door number Durability Seal type Level Key override Seal - head Room number Narrow stile Seal - jambs Room name Handle Seal - bottom Location Back-to-back lock Drop seal type Threshold plate General Panic exit devices Finish Type Ancillary hardware Fire rating Finish Meeting stile trim Door operation Alarmed/Non-alarmed Rebated door strikes Door hand Strike shield Electronic control devices Door stops Door hanging systems Electric strike Door holders Hinge type Electric lock Coat hook Hinge size Drop bolt Buffer coat hook Hinges - No. per doorset Electromagnetic hold-open device Kick plate Sliding track type Keypads Facing panel Floor track type Card readers Edge protectors Floor guide type Breakglass release Escutcheons Sliding door accessories Request to exit Turns roses Push button to exit Blanks Locksets and latchsets Power transfer Door viewer Lock/latch type Door monitor Letter plate type Standard or narrow stile Delayed egress device Signage Backset Door protection Description/action Door closers Lock/latch functional description Closer operation method Keying schedule Handle form Mounting location Door Key-in-knob Installation method Door stamping Knob-on-rose Floor springs Description Knob-on-plate Pivot closer type Level/Area Lever-on-rose Maximum operating force Lock types Lever-on-plate Backcheck Cylinder types Strike plates Delayed action Cam types Sequence selector Quantity Cylinder systems Key head colour Cylinder type Door operators Key No. Keying arrangement Operation method Function description Specification items Lock & latch classification Pivot door operator type Loan cylinders Durability rating Sensor type Construction keys Keying security Sensor location Keying system Cylinder security Sensor mat Keying control security system Physical security of locks Switch type Physical security of locks Miscellaneous Corrosion classification Bolts Bolt length - top Comments Handles, plates, pulls Bolt type - top Pull handles on plate Bolt length - bottom Push plate Bolt type - bottom Pull handle Entrance handle .