Extensible Object Model at the heart of Adroit
One of Adroit’s most compelling benefits is an extensible object model at the heart of the I/O server. For OEMs and Integrators it allows you to create sophisticated, high-performance, display, control, and data acquisition “products” in such a way that the resulting “badged” application effectively appears as your own without the cost and overhead of retaining a large, expensive team of software developers.
Typical Adroit system architecture
The diagram shows a typical system with Adroit I/O and Graphics servers connecting to separate networks: an Office/IT network of client workstations, as well as a SCADA/Plant network of PLCs. Note: it is not essential, just recognized good practice, to separate the plant and office networks. In fact, for simple, standalone applications, there may be no office network at all, in that workstation (HMI) functions and server functions all run in a single PC or tablet.
Objects in the I/O server are called agents in Adroit terminology, and range in type from simple Boolean, Integer, Real types, through conventional SCADA types like Digital, Analog, right up to rich data types that, on their own, implement complete sub-systems such as Alarm Management, Overall Equipment Effectiveness, etc.
By following a few fairly simple development conventions and rules, it is possible for OEMs to add new, rich data types of their own to the Adroit I/O server, and is primarily what we mean by describing the object model as being extensible.
An example of this is marine, ship-board environments where the monitoring required for liquid levels in vessels needs to be radically different to that in static, land-based environments. OEMs in this sector have been able to build their own custom Analog data types that provide delayed level-alarming in which transient threshold overshoots are ignored as the vessel moves around in rough seas.
Other examples of industry-specific data types exist in different industry sectors resulting in the greatest possible fitness for purpose across a wide spectrum of industries.
Another key benefit in Adroit is the availability, at no cost, of dozens of drivers for a wide range of different front-end equipment types. A native Adroit driver exists for all major PLC models including an OPC DA client that will interface to any OPC DA server. But, if you have a very specialized piece of equipment for which a driver does not exist, a new driver can be created in a similar way to which server data types are created. Multiple different types of drivers can concurrently be connected to the I/O server thereby allowing simultaneous control and acquisition to and from many different types of equipment.
FurtherI/O server extensibility comes in the form of several open system interfaces including: OLE Automation, ActiveX Server Control, ADO, OPC DA, and COM Interop
|AlarmTag||Configure an agent for alarming|
|Connect||Connect to a server on a remote computer|
|CreateAgent||Add a new agent directly to the server|
|Fetch||Read a single tag value from the server|
|FetchTags||Read multiple tag values from the server|
|FetchChanges||Retrieve a list of historically logged value changes from the server|
|FetchValues||Retrieve a list of historically logged values from the server|
|GetSlotInfo||Queries information about the different slots constituting an agent|
|Join||Group one or more agents together|
|Leave||Relinquish group membership for one or more agents|
|LogTag||Configure a tag for historical data logging|
|Poke||Modify a single tag value in the server|
|RemoveAgent||Remove an agent from the server|
|ScanTag||Configure a tag for scanning|
Although it may not be obvious from the diagram, there is another interface supported by the Adroit I/O server, that is a really an internal interface used by SmartUI graphics. Because SmartUI graphics are all .NET managed code and the Adroit I/O server is unmanaged code, the AdroitCOM interop DLL is needed to allow these two major subsystems in Adroit to interact effectively.
Even though AdroitCOM.dll is primarily an internal interface, because of .NET support for Intellisense – Intelligent code completion, it is eminently possible, given a proper development environment supporting Intellisense to interact programmatically with the Adroit I/O server from a managed code environment. One use for this kind of thing might be in developing a web-service interface to the Adroit I/O server.
So far we have talked mostly about extensibility within, and interfacing to the Adroit I/O server by creating custom data types or drivers or interacting with external 3rd party products via one or more of the open system interfaces previously listed.
Another area of extensibility within Adroit is in the graphical user interface or HMI created by the SmartUI Designer hosted in the graphics server, and deployed via SmartUI Operator SmartUI is essentially a collection of specialized Windows Forms called Graphic Forms. Individual forms can be considered containers for Controls, either .NET Windows Components or legacy ActiveX controls. There are thus three identifiable ways in which SmartUI extensibility can be achieved: Parameterized Forms, Custom Windows Components, ActiveX Controls:
Some of the available graphic form controls in SmartUI Designer
Read up more on Adroit and get hold of it from the SmartSCADA page