Why information requirements matter for ELV and ICT models

Most BIM disputes on European projects are not caused by bad modelling software. They start earlier, when nobody has written down what each model must contain, who owns each piece of information and when it has to be delivered. For electrical, ELV and ICT services this is especially visible. Device counts change late, containment routes are shared with mechanical services, and the tender drawings for security and network systems are often produced by a different team from the one that models the building.

ISO 19650 gives the international framework for managing information across the asset lifecycle. It is an ISO standard, not EU legislation, and each country adopts or references it in its own way. The UK publishes it as BS EN ISO 19650, and many other national standards bodies and client organisations use the same structure in their procurement documents. Whatever the national route, the core ideas are the same: define the information you need, define who provides it, and check it against those definitions.

The ISO 19650 terms that matter to an ELV designer

Four documents and concepts drive most of the work on a project using ISO 19650 principles:

  • Exchange Information Requirements (EIR). Issued by the appointing party, the EIR sets out the information the client wants at each stage, including the purpose of each model and the format it must be delivered in.
  • BIM Execution Plan (BEP). Written by the delivery team, the BEP explains how the team will meet the EIR. For an ELV package it should name the modelling software and versions, the model naming convention, the coordinate system and the clash-detection routine.
  • Level of Information Need. This describes the geometric and non-geometric content a model element must carry at a given stage, for example whether a CCTV camera needs only a position and a mounting height, or also a view direction, field-of-view zone, IP address and a manufacturer parameter.
  • Common Data Environment (CDE). The controlled place where models and documents are shared, checked and approved. Models move through the states Work in Progress, Shared, Published and Archived. Only Shared or Published content should be used for coordination.

The practical point for ELV engineers is that the level of information is set per object, not per model. A fire detection layout at concept stage can be a schematic. The same layout at tender stage needs device types, addresses or zones where the design relies on them, and cable routes that match the drawings.

Setting up Revit for ELV and ICT content

Revit handles ELV and ICT content well when the template is built around the systems, not around the software defaults. A workable setup usually includes the following:

  • Separate linked models by discipline. Keep the ELV model, the architectural model and the MEP model separate. Link them into a coordination view rather than copying geometry between files.
  • Shared parameters for each system. Create parameters for system type, zone, IP address, VLAN, loop or cable reference and maintenance tag. Use the same names in every project so schedules and exports work without manual edits.
  • Family library based on the product, not the drawing symbol. A camera family should carry the real mounting data, connector type and power requirement, so that the schedule matches the specification.
  • System families for containment and cabling. Cable trays, ladders and conduits modelled as system elements keep routing, fill checks and quantity take-off consistent with the design intent.
  • Worksets or model separation for data and security rooms. Equipment rooms, MDFs and IDFs need their own views and rack elevations, which are easier to control in a separate model or workset.

A practical ELV BIM workflow

The workflow below is one way to organise an ELV and ICT package across a remote production team and a local design lead. It works where the EIR and BEP are already agreed. Where they are not, the first step is to agree them.

  1. Confirm the information requirement. Read the EIR, list the ELV systems in scope and mark which outputs are model-based (device positions, containment, room layouts) and which are document-based (specifications, cause and effect, test schedules).
  2. Set up the template and parameters. Load the agreed families, shared parameters and view templates. Check the coordinate system against the architectural model before any device is placed.
  3. Model from the approved base. Use the latest Shared architectural and structural models as the base. Do not model against superseded files.
  4. Place devices and containment from the design layouts. Each device should be tagged with its system and zone. Containment should be sized to the cable count from the design, not drawn to visual scale.
  5. Run clash detection with mechanical and structural models. Typical ELV clashes include cable trays crossing ductwork, camera poles conflicting with façade elements, and rack clearance in risers. Record each clash with a status and an owner.
  6. Extract schedules and check against the design. Device schedules, cable schedules and containment quantities should reconcile with the design BOQ. Differences must be explained, not absorbed.
  7. Issue to the CDE with a status code. Publish only when checks are complete, with a revision note that states what changed and why.

Coordination and documentation

Coordination is where ELV models usually lose time. Three habits reduce rework:

  • Coordinate by zone, not only by discipline. A reception area may include CCTV, access control, public address, audio-visual and structured cabling. Reviewing it as a single zone shows conflicts that discipline reviews miss.
  • Keep the design intent visible in the model. If a camera is positioned for a specific field of view or an access reader for a specific door swing, the model should carry that note or link to the drawing that shows it.
  • Tie models to the document set. Every model revision should reference the drawing revision it reflects. Without this, the specification and the model drift apart within a few weeks.

Information by stage

The table below shows a simplified way to think about the information an ELV model carries at each stage. The actual level of information must come from the project EIR and the client's standards.

StageTypical ELV model contentTypical outputs
ConceptZones, risers, MDF and IDF locations, indicative containment routesSchematic layouts, space allocation confirmation
Developed designDevice types and positions by zone, main containment, equipment room layoutsDesign layouts, outline specification, preliminary BOQ
TenderDevice tags, system parameters, containment sized to cable counts, rack elevationsTender drawings, device and cable schedules, specification
ConstructionCoordinated routes after clash resolution, as-designed valuesCoordinated drawings, installation details, RFI responses
HandoverVerified as-built data where supplied, asset tags, maintenance parametersAs-built records, asset register input, O&M data

Common mistakes

  • Modelling from an unapproved base. Work done against a superseded architectural file usually has to be moved, which costs more than the original modelling time.
  • Using generic families for everything. Generic families make schedules unreliable. Use product-specific families where the schedule feeds procurement.
  • Ignoring the cable count. Containment drawn to a symbol size and not to the number and diameter of cables leads to overfilled trays at site.
  • Clashing without owners. A clash report with no owner or due date becomes a list of known problems, not a coordination tool.
  • Treating the model as the only record. Specifications, cause-and-effect matrices and test records still need to be controlled documents. The model should reference them.

How remote production support helps

Remote production teams work well on ELV and ICT modelling when the responsibilities are clear. A European consultancy can keep design decisions, system selection and sign-off with its own engineers, while a remote team produces the Revit models, schedules, containment layouts and drawing sets from agreed inputs. This model suits peaks in workload, projects that need a longer model run than the local team can staff, and consultancies that want consistent templates across several projects.

The responsibility split matters more than the location. The remote team should work from a written scope, use the client's CDE or an agreed one, and raise queries through a log rather than by email chains. Quality checks should be built into the workflow, not added at the end.

How ASDV Consultant can support European teams

ASDV Consultant is an India-based remote engineering design and production support partner. We support ELV, ICT and security design teams with CAD drafting, Revit modelling, ELV and ICT BIM production, device and cable schedules, BOQ preparation and drawing production, working from the information your team provides.

We are not a European-registered company, an installation contractor, a commissioning provider or a statutory approval authority. Design responsibility, sign-off and compliance with local regulations remain with your engineers and the appointed professionals on each project.

Technical checklist: ELV and ICT BIM information

  • EIR received and reviewed, with the ELV systems in scope listed.
  • BEP agreed, including software versions, naming convention and coordinate system.
  • Level of information defined for each ELV object type at each stage.
  • Shared parameters loaded and consistent with the client's naming rules.
  • Product-specific families used for devices that feed procurement schedules.
  • Containment sized to the cable schedule, with fill rates recorded.
  • Models linked to the latest Shared architectural and MEP models.
  • Clash reports issued with owners and due dates.
  • Schedules reconciled with the design BOQ.
  • Revision notes and status codes applied before CDE publication.

Frequently asked questions

Is ISO 19650 mandatory in Europe?

ISO 19650 is an international standard. It is not EU legislation. Whether it is required on a project depends on the client, the contract and the national procurement framework. Check the EIR and the national requirements for each project.

What is the difference between an EIR and a BEP?

The EIR is written by the client or appointing party and states what information is needed. The BEP is written by the delivery team and explains how the team will provide it.

Should ELV systems be in the same Revit model as MEP?

Many teams keep them as separate linked models, coordinated in a shared view. This makes ownership clear and reduces the risk of one team overwriting another's work. The choice should be set in the BEP.

Can a remote team produce ELV models for a European project?

Yes, provided the scope, inputs, templates, CDE access and review process are agreed in advance. Design responsibility stays with the local engineers who sign the drawings.

What software do ELV BIM teams usually use?

Autodesk Revit is common for building models, with AutoCAD used for detailed drawings and some containment layouts. The choice of software should follow the client's EIR and the consultancy's own standards.

How do you keep schedules consistent with the drawings?

Use shared parameters and product-specific families, then reconcile schedules against the drawing set at each issue. Any difference should be recorded and explained before publication.

What information should a handover model contain for ELV systems?

The handover content depends on the client's asset requirements. Typical items include device tags, system and zone references, equipment locations and maintenance data. Confirm the format and the fields in the EIR.

Need remote Revit or ELV BIM production support?

Looking for additional ELV, ICT, CAD or BIM production support for your European projects? ASDV Consultant can support your engineering team with remote design documentation, Revit modelling, BIM production and technical engineering resources. Contact us with your project scope and programme, or visit our Europe page to learn more about how we work with European teams.

Sources