Scripting vs Commanding

29th March 2016

Scripting vs Commanding

Many conversations that we have with integration partners and some end users revolve around the use of scripting. Traditionally a lot of project specific, but also sometimes straightforward, HMI or control behaviour could only be achieved by scripting. Users with experience of alternate software platforms therefore tended to focus on running script to achieve their objectives as this is what they were used to having to do.

The ICONICS platform design philosophy is diametrically opposed to this. Whilst a scripting engine is available for use, scripting is actively discouraged as best practise in ICONICS deployments. The key reason for this is the platform’s design goal of “any-glass”. To achieve a solution that can be designed once and then deployed to any client device, with any resolution and any rendering capability, requires that client specific technologies are not used. Whilst VBA/VB/JScript may be viable on a typical Windows desktop PC for example, it is not available on an iOS tablet or an Android mobile device, and if they are, it is to a limited extent. How then would you expect a script based display to be able to potentially run on a mobile or tablet device?

Scripting-vs-Commanding-Medium_5.pngThe ICONICS solution for this is to use a platform feature called Commanding. Commanding is an engine module that allows dynamic commands and behaviours that were typically scripted, to be driven by the system as native functions. This brings numerous advantages. Compatibility with any client is much more easily achieved since the rendering uses native visualisation components. The ability to simply upgrade/enhance a solution without worrying about breaking bespoke code is another big plus. No longer do you need to carry out an extensive review of systems scripts before you can undertake a system update. Most importantly, you don’t have to worry about knowledge loss when the resource that created that code moves on from the business.

This extends further by taking user interface design into consideration. Legacy user interface paradigms such as popups or menus, a traditional staple of the old control room workstation, have no parallels on mobile/tablet and other touch-based devices. HMI design engineers therefore need to accommodate for potentially multiple forms of interaction. It is a different mind-set, but the result is a thoroughly modern, intuitive and flexible interface for the user to interact with.  

 

Written by
Milesh Patel

Milesh Patel