FieldServer for OEMs

More than 200 OEMs have chosen to source and bundle FieldServer protocol gateway technology from Sierra Monitor rather than spend effort on internal development. Many of these OEMs have further chosen to use the FieldPoP™ device cloud along with the FieldServer gateway, rather than develop their own device cloud from scratch. The business rationale has three components:

  • Time-to-market: It can take between 6 and 18 months per protocol to develop, test, and certify internal implementations for popular protocols such as BACnet, LonWorks, KNX, Modbus, Metasys N2, SNMP, XML, etc., and that is after the team has been fully staffed and trained. Using FieldServer IIoT gateways designed specifically for OEMs such as the ProtoNode enables the OEMs to offer support for all popular protocols within 3-4 months, total. Also, the pre-integration of the gateway with the FieldPoP device cloud allow the OEM to save an additional 6-12 months of development.
  • Cost: The expense of developing popular protocol interfaces, certifying them initially, and then constantly staying current with the latest protocol implementations as the standards change can easily creep into more than a million dollars. Maintaining and continuously evolving a cloud “point of presence” requires new skills and additional expenses. Using Sierra Monitor's ProtoNode gateways along with FieldPoP offers a “pay-as-you go” model that delivers a high ROI to the OEM.
  • Risk: Embedded protocol development and compliance testing along with cloud-based software development are distractions to the OEM. It is preferable for OEMs to minimize their risk by leveraging the industry's best in class protocol gateways and device cloud from Sierra Monitor. This allows OEMs to focus on their main business - developing the best devices or systems for their market.

Next: Selecting the Right Partner »

Selecting the Right Partner

An OEM should consider the following critical factors while choosing a protocol gateway and device cloud technology partner:

  1. Does the partner have a demonstrated and successful track record in the multi-protocol gateway business?
  2. Does the partner have a functioning device cloud that works with the multi-protocol gateway?
  3. Does the partner commit sufficient resources to maintain multi-protocol skills and certifications including staying current with evolving standards?
  4. Does the partner have specific experience with other OEMs in the product category?
  5. Does the partner offer a specific turnkey solution consisting of a gateway and the device cloud designed for the OEM, or does the partner offer a generic solution and expect the OEM to adapt to it?
  6. Is the partner able to implement a driver for the OEM's proprietary protocol and map that into the multitude of standard protocols that must be supported, including connecting to the cloud?
  7. How many protocols does the protocol gateway partner support?
  8. Can multiple protocols be supported on the same gateway?
  9. Does the partner offer form factors that are most appropriate for the OEM - ranging from gateways that can be added as an external box to socketed cards for installation on the OEM's electronic assembly?
  10. Is the turnkey solution delivered with pre-loaded and pre-tested profiles so that the OEM never has to download files in the field, and OEM's customers can configure in minutes rather than hours?
  11. Does the partner's gateway technology have the ability to auto discover the types and numbers of the OEM's devices in the field and dynamically build the required configuration on the gateway, thereby reducing field errors and saving time for the OEM's customer?
  12. Does the gateway securely and easily connect to and register with the device cloud?
  13. How user-friendly is the portal for the device cloud?
  14. Does the device cloud offer the ability to securely and remotely access all gateways from the portal?
  15. Can the data from the device cloud be integrated through REST APIs with applications running on other platforms like Google, Salesforce, PTC/ThingWorx, Oracle IoT Cloud, SAP/Hana, Microsoft Azure, etc.?
  16. Can new value-added applications unique to the OEM be developed on the gateway?
  17. Will the partner provide the OEM a customized start up guide, along with training seminars for the OEM's sales and support staff?
  18. Does the partner have the expertise and manpower in protocol translation, embedded software, and cloud technologies to provide deep technical support to the OEM through the entire life cycle - during development, deployment, and post-sales support?

Next: OEM-Appropriate Products »

OEM-Appropriate Products

Sierra Monitor's FieldServer gateways have been adopted by more than 200 OEMs for their protocol conversion, systems integration and cloud connectivity needs. Whether using a ProtoCessor that plugs directly into the OEM's redesigned electronics board, a ProtoCarrier that is added on within the enclosure when the OEM is not ready to redesign their hardware, or a ProtoNode that is assembled in its own mechanical package and mounts outside the enclosure, Sierra Monitor has a FieldServer gateway that is the right fit for the OEM. Sierra Monitor’s combination of FieldServer gateways and the FieldPoP device cloud is the OEM’s perfect on-ramp to the IIoT.

Sierra Monitor and the OEM work together during the engagement process to determine the right products for the OEM’s project:

Learn more about how FieldPoP and FieldServer work together »

Next: The OEM Engagement Process »

OEM Engagement Process

With a track record of working closely and successfully with more than 200 top-tier OEMs, Sierra Monitor has refined its OEM engagement model to avoid surprises and to ensure quick time-to-market. Key steps include: 

  1. The OEM identifies the BMS or local management protocols of interest (if appropriate).
  2. The OEM and the Sierra Monitor team identify cloud connectivity requirements based on how the OEM intends to use remote connectivity.
  3. The Sierra Monitor team and the OEM determine which of the following FieldServer gateway form factors is appropriate for the project:
    1. A ProtoCessor that plugs directly into the OEM’s redesigned electronics board - or - 
    2. A ProtoCarrier that is added on within the enclosure when the OEM is not ready to redesign their hardware - or - 
    3. A ProtoNode that is assembled in its own mechanical package and mounts outside the enclosure.
  4. The OEM provides the register list and data points that need to be translated to the local BMS protocol or mapped to the cloud.
  5. Sierra Monitor creates a unique part number, which contains all configurations that have been developed for the OEM.
  6. Sierra Monitor sets up an account for the OEM on the FieldPoP portal.
  7. OEM receives test samples of all configurations/profiles that have been developed for their product line(s).
  8. Sierra Monitor provides a 60 minute, phone-conference training to walk the OEM through the one-time startup/validation of the ProtoCessor, ProtoCarrier, or ProtoNode. Configurations must be validated before field installation.
  9. The OEM connects the gateway to the FieldPoP cloud.
  10. Sierra Monitor and the OEM determine whether to customize a “premium” package for FieldPoP connectivity.
  11. Sierra Monitor provides a BACnet Explorer capability, allowing the OEM to test their product on BACnet through a PC at their facility.
  12. Sierra Monitor creates a user manual for the OEM to provide for their customers, explaining how to install their products. Manual can be used as-is or modified as OEM sees fit.

Sierra Monitor completes and freezes the programming on the validated configurations/profiles of each of the OEMs controllers for final configuration. There are three approaches for final FieldServer OEM gateway configuration; and the approach used depends on the OEM’s requirements:

  • Configuration Auto-Selector means that all pre-tested configurations are already loaded onto the FieldServer gateway and are selected via DIP switches. Various combinations of configurations are developed and loaded onto the FieldServer.
  • Advanced Auto-Discovery is designed for applications that require one or more of the same device to connect to one FieldServer module to support multiple field protocols without having to build any special configurations. Configuration files are built automatically in the field.
  • Profile Selector/Web Configuration is used for devices without a unique identifying register. The FieldServer module can be set up using the Profile Selector/Web Configurator to select the specific device profile is already stored within the module. This approach can provide the required field protocol(s) for one or more controllers connected to the module.

Protocol Drivers


    No Resources Found