Real Time Objects & Systems, LLC
What is Architecture?
RTOS defines archiectue as the "rules" or "building codes" by which a control device is implimented. A good architecture enables engineers to; "Do the same thing the same way, always." An architecture should be "extensible" meaning whenever a new behavior is needed the addition of that behavior is possible and the new extension does not obsolete any existing behaviors. The architeture should be consistent and thus extensions to the architecture should be intuitive, ideally approaching a "cut, paste & edit" paradigm to enhance its functionality. It should be "granular" meaning it provdes a "get what you pay for but buy only what you need" capability and can thus products can be optimized for size, performance or functionality without changing the architecture components that remain in the final product. XRAE meets and far exceeds these and other archtiecture requirements.
The figure to right shows various Objects, UAPs, a Control Bus, a Configuration Bus, a Hardware platform and various Driver Objects. The Driver Objects provide the glue that binds the Hardware to the totally portable Objects and UAPs. When changing hardware platforms the existing Driver Objects usually require minor modificaitons of the Driver Objects and addition of new Driver Objects where previously unsupported hardware is required. In effect, XRAE objects are utlized to provide all product functionality including that traditionally provided by proprietary and difficult or impossible to modify operating systems.
Since the "EXtensible Realtime Application Environment" (XRAE) utilizes the same software interface for every function of every object class, product functionality is provided by "interconnecting the object functions" within UAPs creating a type of software schematic. In general a UAP approximates a sequential list of function calls to various object functions, where the output of one function is the input to the next function. This common executable interface across all object functions is called "Control Bus" and exists within all XRAE based control devices.
Product requirements generally identify various UAPs that are reused across all control products. A review of the object functions referenced within a UAP identifies the object classes needed within the product. When a network interface exists and where access to the internal UAPs or Object Classes is desired, the Configuration Bus is added. This interface utilizes a traditional interpreted message protocol which effectively references; object class, object service, object instance and optionally service related data. In most existing XRAE devices the Configuraiton Bus seldom provides access to all object classes, object functions or object properties within a control device.
Although shown in figure an XRAE based product; 1) may not contain a network interface, 2) may contain a network interface with predefined interface functionality, 3) may provide device configuraiton capabilites via the Control Bus or Configuraiton Bus and 4) some XRAE devices provide the ability to download new Object Classes and UAPs to the control device to partially or completely alter device behavior.
Relative to granularity, few object classes utilize another object class and thus only those object classes referenced within a UAP need be implimented within a control device. The majority of functions within an object class may be deleted if they are not called by any UAPs with no impact on the operation of the remaining object functions. Relative to optimization, as long as the control bus interface and function behavior is maintained the source code for any object function may be altered to reduce size or increase performance . Extending the behavior of an existing object class can be achieved by adding a new object function with the following conditions. If RTOS is to support this extension it must be provided to RTOS for review and approval, including addition to the programmers guide, creation of test plans, test results, assignment of a unique method/function identifier value and so forth. Ideally behavior extensions are achieved within UAPs utilziing existing object classes where upon occasion new class gets added when an extension is the most efficient manner of achieving new requirements which have not been prevsiously encountered.