About components

Components differ from modules in that components comprise an implementation of the framework, whereas modules comprise the software itself. A component-centric architecture provides the following:

Data normalization
Components provide a model used to normalize the data and features of different types of protocols and networks so that they can be integrated seamlessly.
Graphic development tools
Applications can be assembled with components using graphical tools in the Workbench. This allows new applications to be built without requiring a Java developer.
Application visibility
Components provide unsurpassed visibility into applications. Since components are self-describing, it is very easy for tools to look at how an application is assembled, configured, and to determine what is occurring at any point in time. This provides great value in debugging and maintaining applications.
Software reuse
Components enable software reuse. The framework supports custom development and extension. Its components are extensible and go beyond data and protocols to unify the entire development environment.

About slots

Framework components are defined as a collection of slots. You can see all the slots that make up a component by viewing its slot details on either the Property Sheet view or AX Slot Sheet view.

Figure 13. Slot details for a single component

Slot type — there are three types of slots:
- Property — property slots represent a storage location of another object.
- Action — an action is a slot that specifies behavior that may be invoked either through a user command or by an event. Actions provide the capability to provide direction to components. They may be issued manually by the operator or automatically through links. Actions can be invoked in the Property Sheet view or by right-clicking on the component in the Nav tree.
- Topic — topics represent the subject of an event. Topics contain neither a storage location, nor a behavior. Rather a topic serves as a place holder for an event source.
Slot name — every slot is identified by a slot name that is unique within its type. Slot names must contain ASCII letters or numbers.
Slot definition — slots are either frozen or dynamic. A frozen slot is defined at compile time within a Type's Java class. That means that frozen slots are consistent across all instances of a specified Type – they don’t change. Dynamic slots may be added, removed, renamed, and reordered during runtime – they can change. The power of the framework is in providing a consistent model for both frozen (compile time) slots and dynamic (runtime) slots.
Flags — slots have flags that allow modification of an object’s presentation or behavior. For example, “read–only”, “operator allowed”, and “hidden”, are some of the slot flags that may be used to restrict the presentation or behavior of an object.
Facets — facets contain metadata about an object. For example, “units of measurement” is a type of facet. Facets may be viewed in the slot sheet and edited from a component property sheet.

About master/slave components

Master components can be defined so that persistent properties are copied to slave components when they are changed. This allows you to change a property in one component that automatically updates the components that are linked to it as slaves. In this way a master component can update slave components in all the other stations in a system.

About point components

In any station, all real-time data are normalized within the station database as points, a special group of components. The following image shows several types of control points, as listed in the control module palette in Workbench.

Each type of point may be used for different purposes. When you engineer a job you may want to name a point, for example: a NumericWritable point named CondSetpoint. Points may be named and renamed but they retain their initial point type characteristics and their characteristic icon color.

Points serve as a type of shell, to which you may add point extensions. These extensions allow you to select only those functions that you need and thereby limit your point properties to just those that are necessary for your current application.

About component naming

In a station, components should be properly named using the following set of rules:

Only alphanumeric (A-Z, a-z, 0-9) and underscore (_) characters are used. Spaces, hyphens, or other symbols characters (for example, %, &, ., #, and so on) are illegal in component names. using ASCII code in component names.
The first character in the name must be a letter (not a numeral).
The name must be unique for every component within the same parent component. Workbench automatically enforces this rule, via a popup error message.
Naming is case-sensitive—for example, zone21 and Zone21 are unique names.
NOTE: Case differences among names affect name sorts in table-based views, which order by ASCII code sequence, that is capital letters (A-Z) first, lower case (a-z) following.

To convey multiple-word names without using spaces, naming conventions, such as CamelCase and/or underscores are often used. For example:

Floor1 or Floor_1
ReturnAirTemp or Return_Air_Temp
Zone201_SAT or Zone_201_SAT

Workbench allows you to name components improperly, such as with spaces or other non-alphanumeric characters, without any warning.

Various drivers have learn features to automate the creation of points, some of which (by default) may also have improper names—reflective of the native name of the source object. For example, a BACnet proxy point might have the default name Zone 6 RH%, which matches the actual (native) BACnet object’s name. Be aware that the actual component name has all illegal characters escaped using a $ character, along with the ASCII code for that character, in hexadecimal. The proxy point mentioned above, for example, results in the name Zone$206RH$25, where the $20 escapes the space and the $25 escapes the %. You can see these escaped names in the slot sheet of the component’s parent container. Or, with the component selected, look at its ord (shortcut Ctrl + L) to see its actual name. Other examples include the dash character “-” which is “$2d” and anytime you begin a name with a number, the “$3” is appended to the front of the name.

For the most part, this escaped name scheme is transparent to users. Whenever the name is displayed to the user, say in the Nav side bar, Property Sheet, Wire Sheet, or a Point Manger, the component’s name is unescaped by replacing the code (say, $20) with the actual ASCII character (say, a space). This way, the user sees Zone 6 RH% and so on. This is the component’s display name.

In some cases, escaped names lead to confusion. You should avoid them if possible (rename them). For example, if you add history extensions to escaped-named points, you see those escape codes listed for source points when accessing the History Ext Manager (although associated histories use the display names). Or, if you are building Px pages and manually typing in ORDs in Px widgets, you probably know source points by display names only. If you manually type in an ORD without the actual (escaped) name, the widget binding fails with an error.

NOTE: If this sounds too complicated, remember that drag-and-drop operations resolve escaped names without problems—for example, drag any point onto a Px page to get its proper ORD.

About palettes

The palette provides a hierarchical view of available components. You may copy a component from the palette and paste it where you need it — on a Wire Sheet, Property Sheet, Px View, or in the Nav side bar pane. You can also create custom palettes that you associate with a module and use to hold a collection of frequently used components.