# The Controls Network Riser Diagram: What It Shows and Why It Bounces What a controls network riser must show, from the IP backbone to every MS/TP trunk, what the reviewer checks on it, and the omissions that send it back. The riser is the one drawing in the controls submittal that three different people read for three different reasons. The engineer wants to see that the architecture matches the spec. The owner's IT group wants to know how many switch ports, IP addresses, and VLANs you are about to ask for. The electrician wants to know where your panels need power. Draw it as a pretty block diagram with "BACnet MS/TP" written on a line and all three send it back, each with a different comment, usually on different days. This article is what a controls network riser has to show, what each reviewer checks, and the gaps that get it bounced. ## What the riser is for The panel drawings show what is inside each enclosure. The floor plans show where devices sit in the building. The riser is the logical map between them: every network device, how it connects, and what it connects to, from the operator workstation down to the last terminal unit controller. A good one lets someone who has never seen the building trace a value from a zone sensor to the front end without opening another sheet. It is also the drawing commissioning and service will live with for the next fifteen years. A riser that matches the as-built system is how a technician finds the MS/TP trunk with the dead controller on it at 2 a.m. ## What it shows Work from the top down. Each layer below is something a reviewer will look for on the sheet. **Front end and servers.** Operator workstations, servers, and any web or cloud connection, with their location. If the spec requires a specific front end or an existing owner system, name it. **IP backbone.** Every switch, with its location, port count, and whether you or the owner provides it. Show the connection to the owner's network and mark the demarcation point clearly: the port where your responsibility stops. Show fiber runs between buildings or floors, with fiber type, and copper runs with cable category. Note VLANs and IP addressing, or note that the owner assigns them. A reviewer cannot approve an address plan that does not appear anywhere. **Network and building controllers.** The supervisory devices on the IP network that route to field trunks. Show the device tag, the panel it lives in, its IP address or "by owner," its BACnet device instance, and which ports serve which trunks. **MS/TP trunks.** One line per trunk, labeled with the trunk number, the port it starts from, the baud rate, and the device count. Then every device on the trunk, in physical daisy-chain order, with its MAC address and device instance. Show the end-of-line termination at both ends and where bias is provided. Mark any repeaters. If a trunk leaves the building or crosses a long run, say how. **Gateways and integrations.** Every third-party connection: chillers, boilers, drives, meters, lighting, fire alarm monitoring. Show the gateway, the protocol on each side, such as Modbus RTU on one side and BACnet/IP on the other, and who provides the gateway. A chiller drawn as a box with a line to it is not an integration until the riser says what protocol travels on that line. **Panel locations.** Room number and name for every control panel. "Mechanical room" is not a location on a building with four of them. **Power.** The source for each panel: the electrical panel and circuit, or "by Division 26, circuit to be assigned." Show UPS where the spec requires it for network gear and building controllers. A legend for line types completes the sheet. Use different line styles, solid, dashed, and dotted, for IP copper, fiber, and MS/TP, not only different colors. Risers get printed in black and white, and some reviewers cannot tell your red from your green. ## A trunk, written out The trunk block is where most risers are thin. Here is the level of detail that survives review, written as it would appear in a riser note or a trunk schedule on the same sheet: ``` TRUNK 3 from NC-2 port MS/TP 2, Panel BCP-2, Room 114 Mech 76.8 kbps, 18 devices, termination at NC-2 and VAV-2-18 MAC Device inst Tag Location 1 120301 VAV-2-01 Ceiling, Room 201 2 120302 VAV-2-02 Ceiling, Room 203 3 120303 VAV-2-03 Ceiling, Corridor 2A ... 18 120318 VAV-2-18 Ceiling, Room 230 (EOL) Spare capacity: 14 devices to spec limit ``` Every value on that block can be checked: the device count against the spec's limit per trunk, the MAC addresses for duplicates, the device instances against the owner's assigned range, and the chain order against the floor plan. ## What reviewers check The engineer: 1. Every controller on the equipment schedule appears on the riser, and nothing appears on the riser that is not on the schedule. 2. Device counts per trunk are within the limit the spec sets, with any spare capacity the spec requires. Many specs cap devices per trunk below the electrical maximum, so read your section rather than assuming. 3. Trunk topology is a daisy chain with termination at the ends. Stars and long stubs on MS/TP draw comments. 4. MAC addresses and device instances are unique. Device instances fall within the owner's range. 5. Controller tiers match the spec: the supervisory level, the application level, and what talks to what. 6. Every integration the spec lists is drawn, with its protocol. The owner's IT group: 1. How many switch ports, where, and at what speed. 2. Which devices need IP addresses, and whether you are asking for static assignments. 3. VLAN requirements, internet access, remote access paths. Any remote connection will get read closely; if your spec has cybersecurity requirements, the riser is where they become visible, and [cybersecurity in controls specs](/learn/cybersecurity-in-controls-specs) covers what those requirements usually ask. The electrical side: 1. A power source for every panel, and whether it needs a dedicated circuit, emergency power, or UPS. ## The common bounces - **No device counts on trunks.** The reviewer cannot check the limit, so they ask. - **MS/TP drawn as a bus with "typical" devices.** "VAV, typical of 22" tells nobody which 22, in what order, at what addresses. - **Demarcation missing.** If the riser does not say where your network ends and the owner's begins, the IT review stalls until it does. - **Third-party equipment as unlabeled boxes.** Protocol, gateway, and provider must be on the sheet. - **Panel locations by area, not room.** And panels placed above ceilings when the spec requires accessible locations. - **No power sources.** Then the electrician prices it during construction as extra work, and the change order argument starts. - **Riser and panel drawings disagree.** The network controller shows four MS/TP ports on the riser and two on the panel interior layout. This one is common, and it comes from drawing the riser once and never touching it again while the panel design moved. The network sheet inside each panel's drawing set should come from the same source as the riser; [what a complete panel drawing package includes](/learn/panel-drawing-package) covers that sheet. ## Keep it alive The riser you submit will not be the riser you turn over. Trunks get rebalanced, controllers get added by change order, and addresses get reassigned during startup. Mark the changes as they happen, and the record version at closeout is a cleanup instead of a forensic exercise. ## How Submittal Kit handles this A riser that gets lost between the cover and the datasheets is one the reviewer flags as missing. In Submittal Kit the riser goes in the package where the reviewer expects it: add a Drawings section, or a named Custom Upload, from [configure sections](/help/configure-sections), drag it into place ahead of the product data, and set its empty policy to print a placeholder page so a missing riser shows up on your preview instead of on the review. Link the controls spec section to the submittal so it prints on the cover and transmittal. Compile, and the [submittal package](/features/submittal-packages) comes out as one PDF with bookmarks for every section and item. *Disclosure: I build Submittal Kit. The riser checklist above works whatever you draw it in.* --- Submittal Kit · Field Guides · Updated 2026-10-04 Canonical: https://submittalkit.com/learn/network-riser-diagram