Real Time Objects & Systems, LLC
USER APPLICATION PROGRAMS (UAPs)
A UAP is the interconnecton of software objects to create product functionality, where each object function is represented by a graphical icon and where the actual UAP source code is a "one to one" mapping from the software schematic to source code. Review and modification of product functionality is far more intuitive when viewing "schematics" versus "source code" which significantly reduces product documentation, testing and simplifies product support. Since the UAP code matches the UAP drawing, the UAP is the exact "design" and the exact representation of the implimentation (code) product support and technology reuse is greatly simploified. Unlike any other technology the internal operation of a control device is implimented utilizing UAPs thus enabling the modification of the operation of any aspect of device operation which is only limited by one's creativity and not limited by design decisions made by the product supplier.
NETWORKING
XRAE inteconnects object icons within UAPS to create network interfaces and behaviors. Adding a network interface to a product requires a minimum of six object classes; Timed Relay, Relay, Branch, Producer Object, Consumer Object, and related Network Driver Object. The Producer and Consumer provide a network independent interface to other UAPs where the Driver Object is specific to the supported network and selected hardware. RTOS supports numerous control networks like CAN, USB, Bluetooth, J1939, J1850 VPW, J1850 PWM, J1708 and others can be easily added. Since the UAP drawing graphically represents the network interface behavior the "mystery and complexity" of real time control networks is eliminated. Most existing XRAE products utilize "peer communications" which means systems continue to operate even if other nodes fail, unlike tradtional centralized control systems where controller failure completely shuts down the associated system. Want another message? Copy and paste UAP drawing, change data placed in message to desired values, copy and paste code, make same changes and you are done.
DEVICE BEHAVIOR
All control device behavior is implimented in UAPs where one example is UAP_FAULTS which is contained in most products. When a fault is detected within a control device, how is it identified in your existing products? Is it different in every product? The UAP shown assigns a unique value to each fault name shown (pointed boxes on left). When logic contact to right of value closes, this value is sent to "Set Input 32" of the FIFO FAULT queue object, which captures the value in the order of occurrence. These values can be read/removed vai network by any other products.. To determine what "closes each contact" proceed to the UAP containing the relay or timer shown to fully understand the detected fault scneario. These contacts could have also been used to set "bits in a message" similar to the NETWORKING UAP shown to left, where all fault status indications could be sent in a single message. Yes, XRAE "contacts" pass "data values" as well as "bits". Pretty simple, concise and intuitive? Can you do any of this with your PLC or exiting products?
HUMAN INTERFACE
XRAE is used to create UAPs in all types of devices and includes objects and UAPs for color graphic display devices as well. UAP logic is used to navigate a hierarchy of pull down menus, set text or values at offset locations on a display, change foreground / background colors and so forth. UAPs are available that edit parameter values in other network devices with no prior knowledge of the parameter being edited. The RTOS Process recommends documenting each UAP in a separate document (for reuse) where the operation, test plans and test results are captured in a core document called a "Device Profile". These assets are reused across products where an existing UAP is easily modified for a new products, further reducing time and development expenses. UAPs are NOT limited to "traditional control behaviors" but are used for ALL aspects of a control devices operation and does not require a computer science degree to add or modify device behaviors.