Sedona Framework networks in a NiagaraAX station are unique in that (typically) Workbench provides at least two different levels of data access for an integrated Sedona Framework device:
The (upper) Niagara component level
This level of Sedona data access uses NiagaraAX drivers with components that model the devices, and whatever data items were selected using Sedona proxy points and action points—standard NiagaraAX “station” data. The Niagara station communicates to Sedona Framework devices using the Sox protocol at the application layer, with lower layers either Ethernet/IP (or 802.11 WiFi) if a SedonaNetwork) or Jennic 802.15.4 / 6LoWPAN (wireless) if a SedonaJen6lpNetwork.
This document is mainly about this data access level.
To fully support the new Sedona TXS-1.2 features for Sedona device access, it is recommended you install all appropriate “Sedona
environment files” used by these devices on the host (e.g. JACE) platform. These include the kit files and platform files,
as well as the kit manifest files. Refer to JACE workflow and Installing Sedona environment files in a JACE for details. Otherwise, to be able to discover and add Sedona proxy points, the JACE or Supervisor (station host) requires,
at a minimum, the kit manifest file for each Sedona kit that is installed in any networked Sedona Framework device. You can
do this in a station connection to the host, using the “Manifest Manager” view on the Sedona Framework network.
The (lower) native Sedona component level
This level of Sedona data access uses either the “Sox Gateway” and “Sedona Tools” provided under each networked Sedona device, or else a direct Sox connection or a “tunneled” Sox connection from Workbench through the running station.
Once Workbench is connected to a Sedona Framework device, Sedona provisioning of it may be possible, as well as making Sedona “app” changes to its components, including properties and links.
To be able to open a Sedona Framework device in a direct Sox or tunneled Sox connection, the Workbench PC (host) requires
the kit manifest file for each Sedona Framework kit installed in the device, as the Sox client is Workbench-based. However,
starting in Sedona TXS-1.2 “Sox Gateway” access does not require the Workbench host to have manifest files, as the Sox client
is based in the running station. Also a station does not require the SoxTunnel service to support Sox Gateway access. For
these reasons, it is expected Sox Gateway access to be used most frequently for Sedona app changes, and Sedona Tools (under
each networked device) to be most frequently used for provisioning.
For related details, see Sedona device "tools" views, Sox Gateway. and Sedona environment management.
In addition, devices based on Sedona Framework 1.2 may have the ability to “host and serve” kit manifests to a Workbench or station client, such that app access can automatically resolve manifest dependencies if not already present in the client’s Sedona environment.
CHoPAN component access level
For SedonaJen6lpNetworks (only), an available “CHoPAN” (or simply Chopan) component access level uses a client-server architecture. Chopan provides Sedona proxy point polling advantages, providing that Jennic-based devices are configured and enabled for Chopan server operation.
Chopan also allows a device’s Sedona Framework app to directly access data in other networked devices, or in the JACE station (providing they are Chopan servers) via client-side “Chopan points”.
For hibernating Jennic-based devices, Chopan client configuration (Chopan points) must be used to access all data, instead of using Sedona proxy points.
At the time of this document, Sedona Framework support for hibernating devices (typically battery powered devices) is not
widely available. However, the SedonaJen6lpNetwork driver in the NiagaraAX station is “ready” for such device support if this
changes.
Client-side components in a Jennic-based device’s app are added via Niagara access to the JACE station, in the “Chopan Virtual” gateway under its corresponding SedonaJen6lpDevice component. See About the Chopan Virtual gateway for related details. This document summarizes various Chopan-related components and views in the explanation of the SedonaJen6lpNetwork, but complete Chopan details are in the Sedona Framework Chopan Usage document.
In general, before engineering the upper (station) level with Niagara Sedona proxy points and action points, it is recommended
to develop and complete the (native) Sedona Framework app running in each Sedona Framework device. Otherwise, data address
mismatches between Sedona proxy points in the station and the source Sedona Framework components in a device are likely to
occur.
Copyright © 2000-2014 Tridium Inc. All rights reserved.