“It’s just a firmware flash” they said. “It’ll be fine.”

“It’s just a firmware flash” they said. “It’ll be fine” they said. They were wrong.

BACnet is a very extensive protocol, covering not just communications but also data structures and behaviors. The BACnet standard not only specifies a way of crafting UDP or MS/TP packets for transmission, but also ways of defining and using schedules, alarms, and even point types. These specifications are subtly different from the behavior of Siemens P2 systems in many important ways. A few of them to consider are:

BACnet is a very extensive protocol, covering not just communications but also data structures and behaviors. The BACnet standard not only specifies a way of crafting UDP or MS/TP packets for transmission, but also ways of defining and using schedules, alarms, and even point types. These specifications are subtly different from the behavior of Siemens P2 systems in many important ways. A few of them to consider are:

• Alarms
  The P2 system had a fantastic “enhanced alarm” utility that does not have an analogous feature on the Siemens BACnet side. These alarms will have to be reviewed and converted to programming-driven alarms or BACnet event-based alarms. I suggest combining this effort with an ISA 18.2 alarm audit to reduce the number of nuisance alarms that you pay to re-create in the new system.
• MSV/LENUM
  There is a very common point type, called a “LENUM” in Siemen Apogee and “MSV” in BACnet. These point types define discrete state values that correspond to text descriptions of that state. They are typically used to control the flow of program execution. Apogee LENUMs are allowed to have a state of 0 (usually corresponding to OFF), whereas BACnet MSVs start at 1. LENUMs can have undefined states between two numbers. For example, it’s not uncommon to have a 3-state LENUM with state values like 0, 2200, and 2300. This is not acceptable in a BACnet MSV, which must include all the integers between two values in its definition. Either configuration will have to be identified and changed in advance of a BACnet cutover, or the programs that use them will behave unpredictably.
• OIP/Shell scripting
  Siemens PPCL programming has a command called an “OIP”, which executes a shell script inside the panel. It is a very powerful command that should be used with extreme caution. Since the Siemens BACnet field panels have different firmware than the Siemens P2 panels, these statements will not do whatever they were originally intended to do. This is a relatively unusual case that has the potential to cause significant problems.
• Crosstrunk to BBMD
  If buildings are sharing data, they will need to be able to continue doing so. Siemens Apogee had a service (Crosstrunk) at the server that moved communicated point values from one BLN to another, if necessary. BACnet does not need this service if certain specific requirements are met. It is unlikely that a campus-style site will consistently meet all these requirements without intentionally planning to meet them.
• Manually Unbundled Points
  There currently appears to be a firmware incompatibility that causes manually unbundled points (points created in a panel with the same address as a subpoint on an FLN device) from working properly.