digitalplan-en:fileformats-en
Forskjeller
Her vises forskjeller mellom den valgte versjonen og den nåværende versjonen av dokumentet.
Begge sider forrige revisjonForrige revisjonNeste revisjon | Forrige revisjon | ||
digitalplan-en:establishment-en [2022/01/18 07:45] – stun | digitalplan-en:fileformats-en [2022/01/18 08:30] (nåværende versjon) – [Professional responsibility] stun | ||
---|---|---|---|
Linje 1: | Linje 1: | ||
- | ===== File formats ===== | + | ===== 10 File formats ===== |
Bane NOR requires open international file formats, and supports the development of these. Until these formats are available for all subjects in transport, other formats can be delivered by agreement with the individual projects. | Bane NOR requires open international file formats, and supports the development of these. Until these formats are available for all subjects in transport, other formats can be delivered by agreement with the individual projects. | ||
- | ===== Requirements for software tools ===== | ||
- | Establishment of a model that is to be integrated with other models requires requirements for computer tools that meet this. A recognized design tool must be used that satisfies given requirements: | ||
- | T * here are no requirements for which software is to be used for models, but the supplier must choose software that gives Bane NOR license-free access. Web-based solutions that are installation-free are encouraged | ||
- | * The program and functions must be tested and tested in advance. Calculations performed by the program must be quality-assured and be documented on the basis of current ICT standards. | ||
- | * Quality: The accuracy of the display unit of the program must satisfy the requirements for input data. | ||
- | * Mobility: It must be possible to move in the model without time interruptions or delays. | ||
- | * Content structure: The program must be able to read all formats to be used in the project from all actors, without distortion or loss of data. | ||
- | * Deliveries of stitching data must be in a known format - Land-XML or KOF. | ||
- | * It must be possible to prepare drawings and sections of parts and the entire model as a section or in plan according to given drawing rules. | ||
- | * It must be possible to generate volume and mass calculations of the model. | ||
- | * The model must be able to be used for control when comparing the volume model and measured data of construction activity performed. | ||
- | * It must be possible to generate final documentation of the model and associated data. | ||
- | * Objects in the model should be able to carry information in the form of properties for description of properties, location, dates, operating instructions, | ||
- | In the absence of documentation or fulfillment of these requirements, | ||
- | ==== Data security ==== | ||
- | All data files must be on the project' | ||
- | ===== Drawings in addition to model ===== | ||
- | There is a need to make some drawings in addition to the model. Documentation in addition to the model will change as digital data can replace drawings and forms. The starting point is that all drawings are generated based on the plan model so that the interfaces between the drawings are taken care of. | ||
- | A drawing can contain both schematic and floor plan. A schematic drawing shows functions and connections in the system, everything from track plans to electrical systems. There are separate subject-specific requirements for such schematic drawings, often with separate symbols as shown in the Symbol Library. | ||
- | There will also be a need to make schematic drawings and detail drawings. (drawings not oriented in the coordinate system). These can be: tables, cable plans, connection plans, line layouts, line calculations, | ||
- | |||
- | Deliveries of documentation are in principle governed by the current contract or agreement. | ||
- | |||
- | The client has an expectation that the delivery covers the need for complete documentation within each subject. The delivery must contain sufficient information to be able to assess whether the content of the design meets all technical requirements and with a correct goal achievement. The accuracy must be within the framework of quality set in the given planning phase. Delivery must be checked through quality assurance before dispatch | ||
- | |||
- | The delivery must be made according to the project' | ||
- | |||
- | Missing or poor delivery or documentation is considered "not delivered" | ||
- | |||
- | ==== Rules for names of layers in drawings ==== | ||
- | |||
- | Subject code should be the first part of the name of the team. Then the name must be categorized and detailed depending on the subject and object type according to the tables on the following pages. All " | ||
- | |||
- | * THEME_CATEGORY_DETAIL * _THEME and _CATEGORY (as indicated in the tables below) should not be changed. | ||
- | |||
- | If necessary, it can be supplemented with additional _CATEGORY. If more DETAILS are needed, this can be specified in each individual project. | ||
- | |||
- | Automatically generated teams should keep their names. This applies to objects made according to NS3451 building component table and the like Naming requirements only apply to teams that are manually named. | ||
- | |||
- | ^ THEME ^ Description | ||
- | | JBT | General designation of railway technical layers in the drawing. | ||
- | | JBTEL | Railway technical low voltage systems (NS 3451 (ELI) and NS 8351 are used where this is natural| | ||
- | | JBTEH | Railway technical high voltage system (50Hz high voltage system - not Catenary / current) | ||
- | | JBTJORD | ||
- | | JBTKL | Overhead contact line system | ||
- | | JBTEF | Track power supply system | ||
- | | JBTOB | Superstructure | ||
- | | JBTTE | telecommunications systems | ||
- | | JBTSI | signaling system | ||
- | |||
- | Table shows codes for naming themes in team names | ||
- | |||
- | ^ THEME ^ Description | ||
- | | JBTEL_EKS | ||
- | | JBTEL_PROSJ | ||
- | | JBTEL_ALT1 | ||
- | | JBTEL_FASE10_SPV2_SSS | ||
- | |||
- | Table showing examples of team name usage | ||
- | |||
- | |||
- | ==== Requirements for information in drawings ==== | ||
- | |||
- | The mileage should be increasing from left to right. | ||
- | |||
- | ** Information in the title field: ** | ||
- | |||
- | * Scale: Include which sheet format the scale refers to (A1). Many drawings are scaled up or down when copying | ||
- | * Drawing name must follow the subject code given in STY-605016 and Naming of design documents. | ||
- | * Revision: The first drafts of a drawing get revision 00, 01, 02, etc. The first official edition starts the revision at 00 again, and at the same time gets the letter A (00A) added. | ||
- | |||
- | All previous editions are removed from the revision field. The next revision will be 01A, 02A, etc. The letter A applies to concept / solution proposals (report, master plan, detailed plan and building plan). Drawings prepared for the tender basis are given the letter B (B revision). Job description and working drawings get revision letter C (C revision). There are also separate provisions for what information must be stated on plan maps prepared in accordance with the Planning and Building Act, see Guide to the Map and Planning Regulations and National Product Specification for Area Plan and Digital Plan Register. | ||
- | |||
- | ** Other information / endorsements: | ||
- | |||
- | * North arrow (preferably near the title field so that it appears on the front when folding the drawing) | ||
- | * Grid and / or scale ruler | ||
- | * Coordinate system: - for example: «Horizontal: | ||
- | * Source reference (name of owner / licensee for map data) - for example: «Source: Geovekst», Source «Oslo kommune» | ||
- | |||
- | ==== Quality assurance ==== | ||
- | |||
- | All subject models and drawings must be updated at the same time. Designers must review the procedures for quality assurance of the content. If no other quality assurance methods have been agreed, the underlying points must be used: | ||
- | |||
- | |||
- | Prepare control plan after[[https:// | ||
- | |||
- | * Use of professional checklists. | ||
- | * Interdisciplinary review of model and drawing production. | ||
- | * Simultaneous revision, delivery and publication of profit models and drawings. | ||
- | * Review and signing of the work together with controlling and approving digital deliveries. Signature / electronic signature is applied to the version handling table. | ||
- | |||
- | No changes must be made to the model after the project has given it the status approved. The implementation of the quality assurance must be documented and follow the project. | ||
- | |||
- | |||
- | ===== Stitching data in model ===== | ||
- | |||
- | Stitching data in the model with layers that have the prefix " | ||
- | |||
- | ===== Control of production ===== | ||
- | |||
- | The model can be used for the reference of control and approval of the location and extent of various elements and objects in the facility. Based on measurement data of the built elements and objects, a geometric quality plan is created that describes different intermediate and projected elements. | ||
- | |||
- | Stated deviations and tolerances appear in contract documents and in technical regulations, | ||
- | |||
- | Measured data is provided by the contractor as " | ||
- | |||
- | In addition to " | ||
- | |||
- | If the measurements show that an object has been built outside the tolerance requirements, | ||
- | |||
- | **Measurements must be sorted into the following categories: | ||
- | |||
- | * As built control points within tolerance requirements. Requires no revision of model. Objects automatically get "as built" status. | ||
- | * Which built control points outside tolerance requirements, | ||
- | |||
- | Approved "Som Bygget" | ||
- | |||
- | Some deviations outside tolerance requirements can be considered by designers as " | ||
- | |||
- | * As built measurements of new or finished objects without plan data, used by designers to create new "as built" objects in the model. | ||
- | * Measurement of existing facilities. The client and designer agree on what may be modeled. | ||
- | |||
- | If "as built" measurements entail changes that are important for the further construction, | ||
- | |||
- | ===== Upgrade to "as built" model ===== | ||
- | |||
- | After feedback from the contractor, the designer shall upgrade the following models: result, display, coordination and source model to "as built" status. | ||
- | * All updates are based on the contractor' | ||
- | * Designers shall continuously upgrade all performance models to "as built" status in accordance with the contractor' | ||
- | |||
- | ===== Approval of models and drawings | ||
- | |||
- | All models and drawings must be checked and approved before delivery as described in the project' | ||
- | |||
- | The delivery is accepted by the recipient before these are considered delivered. | ||
- | |||
- | ===== Reporting, documentation and archiving ===== | ||
- | |||
- | Updates of basic data / planning material must be documented. Everyone in the project will be informed about such updates. | ||
- | |||
- | Reporting from advisers must be in accordance with the contract / agreement. Documentation shall not be sent directly from the consultant to the contractor without this having been agreed with the client / project. In all cases, the client must have a copy of the shipment. | ||
- | |||
- | * Guidance should normally be integrated into the tool | ||
- | * In cases where this is not possible or the explanation that comes with the tool is too bad, a separate document is created called Guidance | ||
- | * Guidance includes a detailed description of what or how a tool such as a computer system or other type of tool should be used | ||
- | * Guidance may include requirements for the tool to be used correctly or for the result to be correct | ||
- | * Guidance must be linked to the activities stated in the management system | ||
- | |||
- | The revision field and header retrieve data from the document profile in the ProArc archive system. Fill in the document profile. These fields in the document do NOT need to be changed manually. | ||
- | |||
- | ===== Professional responsibility ===== | ||
- | |||
- | The BIM manager in Bane NOR has overall responsibility for the field. | ||
- | |||
- | The BIM manager is responsible for reporting the status of his or her areas of responsibility within set deadlines and with good quality, in accordance with regulations that apply at all times in the associated division. |
digitalplan-en/fileformats-en.txt · Sist endret: 2022/01/18 08:30 av stun