atvise_HG_o_logo

AI needs structure. atvise® has had it since 2006.

The answer is already in the project. You must be able to access it.

atvise® and AI: Why open standards determine whether artificial intelligence delivers value in automation - and what the team is currently working on.

An example:
- A plant reports a fault.
- The responsible technician is not on site.
- The colleague filling in does not know the project.
- He does not know why an alarm is configured the way it is.
- Which script is triggered where?
- But: the information is already in the system!
- It is stored in the project, the documentation and the log files.
- It is simply not accessible at the moment it is needed...


This is exactly where artificial intelligence in automation becomes interesting - not as a replacement for subject matter expertise, but as a path toward it. And this is exactly where it becomes clear that the crucial question is not the model, but the system underneath it.

An assistant is only as good as its access to the system

A language model does not know the system. It can only answer what it can read. In a closed system this means: It reads very little and what it does read must be provided via custom-built intermediate layers. Each of these layers represents effort, a source of error, and a dependency.

With atvise® this detour is eliminated. The foundation for this was laid long before the current AI discussion.

AdobeStock_824068968_KI_lichtpunkt_bearb_web

Three Essentials for AI: atvise® has them.

For an assistant to work with a plant, it needs more than a language model. It needs structured access to information, an environment for application, and open interfaces to the outside world. These foundations have been part of atvise® for years.

1 / 3

01 - Everything resides in the address space

In atvise® OPC UA is not just aninterface among many, but the core. 

The entire plant – project structure, variables, methods, alarms, history, and metadata – resides in the OPC UA address space and can be queried via a standardized, vendor-neutral method; it is typed and consistently object-oriented. The atvise® builder itself is an OPC UA client. The structure an assistant would use is exactly the same as the one engineering teams have always used.

For a model this means: It does not have to guess anything:

  • No proprietary configuration files to interpret.
  • No screen content to analyze.

Anyone who has engineered a plant in atvise® has implicitly already described it in a way that a machine can understand.

interoperability

02 - Web Technology as an Open Foundation

AI functions need to be able to emerge where work is already being done.

atvise® was developed from the start using HTML, JavaScript and SVG. Assistive functions therefore require neither a separate runtime environment nor additional client deployment.

They run where work is already being done:

  • in the browser,
  • device-independent, and
  • without plug-ins.

This means the technical foundation is already in place to integrate AI functions directly into the existing visualization environment.

istockphoto-1144557228-1024x1024

03 - Open means interoperable

The third requirement is the outward connection and atvise® provides that as well.

HTTP, TCP, and ODBC clients; import and export options via XML and CSV; and an open scripting environment based on JavaScript. The same mechanisms that currently support integration with MES, ERP, and cloud systems also support integration with AI services.

  • No new communication layer
  • No additional investment in custom interfaces
flbl_opc_ua

The foundation for AI has been in place for years:

  • OPC UA structures the information.
  • Web technology makes it accessible everywhere.
  • Open interfaces, scripts, and OPC UA methods provide the path to the outside world.

What AI applications need today is therefore not an entirely new technological world. They build on an architecture that has shaped atvise® for years.

500_F_332215667_FRtsNh6JCtsstNqBlLmiP5dixFFWNJfS

Current Status

The atvise® architecture has been systematically analyzed to determine where AI provides real value and where it does not. The first assistive tools have been developed and are currently in trial operation:

  • tools to assisst Dashboard configuration
  • Documentation
  • Application-related questions

The greatest potential lies not in runtime operation, but in engineering. This is where a significant amount of effort is generated that can be reduced substantially with AI assistance. It is also where errors can be identified and corrected before they affect the plant. In the engineering role, agents can support tasks such as generating scripts, displays, or object types.

In runtime, agents play a different role, depending on their tasks and the way they access the process image:

Reading

non critical

Tools and agents can read information.

Writing 

Critical

Process interventions and write operations require control.


In automation a misspelled variable can alter the set value, destroy a display, or override an alarm configuration. 

That is why the principle is adhered to: 

  • Every intervention by an assistant requires explicit human approval.
  • Every suggestion must be reviewed. 

What comes next...

...the foundation is in place.

icon_hr_mobilität_rgb
The direction is clear.

We will continue this work over the coming months and show what emerges from it.

  • You’ll be the first to know, right here.