The implementation of SVG animations in SCADA uses Javascript to access or traverse through SVG DOM periodically to achieve animation effect. As for example, color animation is predefined to listen to a tag value. In real life application, a pump status can be "running", "stopped" or "trip". Each of these status can be represented by color like "green", "red" and "amber" respectively. The Javascript module will then change the color of SVG object to user configured color based on the associated field value, which being feed constantly via AJAX. For instance, value "0" represents "stopped" (red), value "1" represents "running" (green) and value "2" represents "error" (amber).

For a state-oriented application such as SCADA, it is unsuitable to use native SVG animation which is restricted in terms of interaction. There used to be consideration of making use of beginElementAt() and endElementAt(), which are Javascript functions in SVG specification, to stop SVG animation at a state. However, these methods are still based on timeline. Calculations to convert state to time is another cumbersome work. To overcome this problem, additional Javascript function is required to change the object property periodically.

IntegraXor SCADA Animation Code or XSAC is a JSON based syntax that contains animation settings for a graphic object. Among the common SCADA animations are: Color, Level, Movement, Opacity, Rotate and Text. This paper will focus more on the first five animations, since similar animations are already available in native SVG. Even though these animations are achievable in SVG animation, however, they were not designed to work with state condition, and doesn’t support external interaction. For example, animateColor can only animate from 1 color to another, with a specific begin time and duration, and option to repeat the animation.

Below are examples of XSAC and comparison table with native SVG animation. Note that the listed XSAC syntax have been simplified and slightly tuned to ease the understanding in comparing towards native SVG animation.

To replace native SVG animation, the XSAC engine takes in an important role. It is responsible for collecting all configured tasks and perform accordingly, while keep checking on new data update from SCADA server. Once there is new update on a particular tag, it will then set the properties into the SVG object.

The above examples show sample syntax of XSAC, which the Javascript animation engine will process. "attr" (abbreviation of attribute) defines the task to perform, "tag" is the data to listen, and the rest are parameters for action.

However, by setting the properties, the animation looks sluggish. Smooth animations we can see in native SVG animations will no longer possible. Rotate animation was forced to behave in ‘stages’, i.e., 1 rotate action moves 36 degree, for 10 times to complete a cycle.

There is a workaround to retain SVG animation in SCADA applications, that is by appending the ‘animate’ element into SVG object each and every time the state or the associated tag value is changed. When the state is changed, the previous animate element will be removed. This, however involves SVG DOM manipulation and might introduce heavy CPU load and memory consumption since a SCADA application might have more than hundreds of working I/O in a single page depending on the type of hardware and size of the plant.

In order to retain the animation effects in native SVG animations while avoiding the cumbersome workaround stated above, we propose to add state-oriented animation onto the existing time-oriented animation. The state-oriented animation shall preset a number of animations into an attribute, and execution determined by another attribute called "state". Below is the list of example of usage when "state" attribute is added.

Current SVG animation are time-oriented animations, which are run with specific begin/end time and duration. It can be repeated, showing an animation in a sequence repeatedly. SCADA applications require instant animation change when associated data is being updated, thus making existing SVG animation unsuitable.

State-oriented animations are proposed to enhance SVG animations to allow animations toggle by states or variable. On every state change, a pre-configured animation will perform according to which state the object is in. By adding states to animations, user can further enhance SVG animations into condition-based, therefore fulfill the requirement of SCADA and other state-oriented applications.

The suggestions we have made above might not be sufficient to other applications such as games, simulations, presentations, etc. This idea is base on the requirements of a SCADA system, and is yet to revise to be useful to these applications. Studies of methods to utilize state-oriented animations on these applications should be carried out to refine the above proposal. However, we hope this paper can be taken into account, to make SVG unique among other technologies in this fierce competition.