Define integration responsibilities across specialty vendors

What you should be able to do

Create a responsibility map that connects a source system, an interface and a destination outcome. Explain why individual vendor tests do not replace integrated functional acceptance.

Scope

This is a project-coordination lesson for low-voltage apprentices. The example assignments are original teaching aids, not contractual or legal interpretations. The actual project scope, approved design and designated acceptance authority determine responsibilities. No live programming, credentials, control commands or safety-system modifications are authorized by this lesson.

1. Define The Outcome First

A statement such as “integrate the systems” is too incomplete to test. Replace it with a specific, approved behavior: when a defined source condition occurs, the required destination must show the correct identity and state, with the required response and restoration behavior.

For the classroom example, a fictional leak controller reports Zone L1 to a facilities dashboard. The required display is “Room B — Leak.” The example performs monitoring only; it does not command a shutoff valve or change a life-safety system. Adding those actions would require new approved requirements, responsibilities and testing.

2. Assign Owners On Both Sides

The source vendor demonstrates the agreed event and its documented representation. The receiving vendor demonstrates how the destination processes and displays it. An assigned integration lead coordinates translation, mapping and the complete chain. A project lead manages unresolved scope questions and the designated authority accepts the required outcome.

These roles can be held by different organizations or combined in one organization. The important point is a named accountable person or team for each task, not a mandatory organizational chart. Record the assignment before testing so a gap does not become “someone else's problem.”

An apprentice can help label interfaces, gather approved documents and record observations. The apprentice should not resolve a contractual scope dispute or assume authority to alter another vendor's configuration.

3. Write An Interface Record

For each connection, record its source, destination, permitted direction, data identity and expected meaning. Add the actual model, software or firmware version, supported functions and approved communication method. Specify who provides connectivity, power, configuration, access credentials and ongoing support.

A binary value is not self-explanatory. In the fictional example, determine whether a value represents a present alarm, a latched event, a fault or a normal state. Include what happens when the source returns to normal or becomes unavailable. An unlabeled number on a dashboard is insufficient evidence that the intended condition is understood.

BACnet's Protocol Implementation Conformance Statement, or PICS, identifies the capabilities implemented in a particular product. The BACnet Committee explains its use in product selection and integration. Use the actual product documentation to check needed functions rather than treating the word BACnet as a complete feature list. [1]

4. Verify The Version And Required Features

ONVIF states that conformance is tied to a specific product firmware/software version and the claimed profiles. Its process includes mandatory and applicable conditional features. Check the appropriate registered product and documentation for the version being used. [2]

This illustrates a broader project habit: record what was actually tested. A product-family name or manufacturer's membership in an organization is not the same evidence as the specific implementation and required feature support.

Compatibility evidence and project acceptance answer different questions. Standards-related information can support selection, while the site test must still demonstrate the required mapping, configuration and end result. Do not promise every optional feature merely because the products use the same named protocol.

5. Include Shared Services

The interface may depend on approved network paths, addressing, time services, power, accounts, certificates, licenses or other services. Identify the responsible owners. Include those prerequisites in the test plan rather than inviting vendors to a test with missing dependencies.

Record read-only versus control permissions explicitly. A monitoring requirement is not permission to write commands. Do not expose passwords in a teaching worksheet or handover screenshot; use the organization's approved method for account management.

6. Test The Whole Chain

In the original exercise, Vendor A demonstrates the correct L1 event at its output. Vendor B's dashboard displays “Room C — Leak.” Source generation passed that observation, but integrated location mapping failed. Keep both facts in the record rather than declaring either that nothing works or that everything passed.

The integration lead coordinates diagnosis against the approved map. After an authorized correction, repeat the affected case and related checks required by the test plan. Keep the initial failure and corrective action traceable; do not replace the record with an unexplained green check.

Define acceptance criteria before the test. Include expected normal, event, fault and restoration behavior where applicable. If a response-time criterion is required, specify the measurement points and time basis. This lesson does not invent a universal delay limit.

7. Hand Over Ownership, Not Just Equipment

The handover should identify the tested configuration, outstanding issues, support contacts and change responsibilities. Record who maintains mappings when a room is renamed, an endpoint is replaced or firmware changes. A system that works today can lose required behavior after an uncoordinated change.

Do not equate training attendance with technical acceptance, or a vendor's local test with acceptance by the project's designated authority. Keep those records distinct and link them to the approved requirements.

Practice

Create a one-page interface record for the fictional L1 example. Name the source owner, mapping owner, destination owner and acceptance authority. Add one shared dependency and one unresolved question. Write a test with expected and actual outcomes for the wrong-room condition.

Knowledge Check

Sources

Worked through

In the fictional L1 test, the source vendor demonstrates Zone L1 correctly, but the receiving dashboard displays Room C instead of required Room B. The source observation passes; the integrated identity check fails. Assign the mapping discrepancy to the named integration lead, preserve both observations and retest after the authorized correction. Do not give a monitoring interface control permissions while resolving the map.

Where beginners go wrong

Where beginners go wrong