The purpose of this article is to help to understand the requirements and the installation process of OSHMI.
System Requirements And Tuning
The hardware requirements will depend on the size and architecture of the system.
For a small system like a single substation up to 3000 tags, a cheap machine can take care of the load.
Recommended minimum hardware for most use cases:
Intel Core I5 or AMD Ryzen 5 processor, 4GB of RAM, 250GB HD, 4k capable GPU, 27″ UHD monitor, Windows 10.
For sure it is possible to use a less capable system, but this possibly will require some additional tuning and testing. For example a server only machine can have only 2GB of RAM and a slower processor (e.g. Intel Atom), this can enable the use of a fan-less rugged hardware.
For Control Centers typically processing 50k tags or more, it is recommended a more capable hardware:
Intel Core I7/AMD Ryzen 7 processor with 4 nuclei or better processor, 16GB of RAM, 512GB SSD, 4k capable GPU, 27″ or greater UHD monitor, gigabit ethernet, Windows 10.
It is possible to use also older versions of Windows. I recommend Windows 10 because it manages UHD 4k monitors in a much better way than the older versions. Even Windows XP can be used but in this case, it is necessary to use an older version of the Chromium browser, 49 is the last version compatible with Windows XP (‘chromium_browser_for_win_xp.zip’ package in the OSHMI Sourceforge Files section).
Some Windows tuning sometimes helps a great deal in the performance and responsiveness of the system. Some simple measures that can help (try them one at a time until you reach good performance):
Uninstall all the manufacturer bloatware and other unessential software.
Disable all energy economy functions, put the system in the maximum performance option.
Remove unnecessary Windows features (as Vista Gadgets, tablet extensions, etc.).
Disable Windows UAC.
Disable some Windows Services such as Ready Boost, Super Fetch, and Windows Search.
Disable Windows Firewall.
Do not use third party antivirus, prefer Windows embedded protection tools.
Disable Windows real-time and cloud-based protection.
For mobile clients, it is necessary only a modern HTML5 browser like Chrome, Firefox, Opera or Safari. The performance of SVG Screens can be bad for old or underpowered devices. In general, an intermediary priced current device can handle SVG processing with good performance. Very complex screens with many objects and animations may require a top performant device like expensive flagship phones or tablets.
As stated in the previous article, OSHMI aggregates various open-source projects in a single easy to install package. All the system is pre-configured with reasonable defaults and the required intervention in the configuration files is kept to a minimum.
After the setup ends go to c:\oshmi\extprogs and run download_external_progs.bat, this will install some optional utilities and the screen editor Inkscape+SAGE.
The install and updates cycle is designed not to overwrite configuration, database and screen files. So when a new version is installed all the current state of the system is expected to be preserved. None the less I recommend a backup before installing a new version (especially for the conf, svg, charts and scripts folders).
The more important folders under the c:\oshmi are (see the complete list in the configuration manual):
bin – executable files
conf – configuration files
db – database files
docs – documentation
htdocs – HTML5 files
svg – display screen files
nginx_php – web server and scripting engines
The setup program creates an OSHMI folder on the desktop. This folder contains shortcuts to many system files and functions. To quickly test the installed system, execute the “_Start_OSHMI” shortcut. This will execute the server subsystem and open the Screen and Alarms Viewers. The system is preconfigured to run a simulation with example point list and screens. To simulate a command, click on a breaker and push the “Command” button then choose an action like “OPEN” or “CLOSE” and push the action button. To stop the system click on the “Stop_All” icon in the OSHMI folder. To edit and create new SVG screens use the Inkscape+SAGE editor.
By default, the system is configured to allow only HTTP access to the local machine (localhost, 127.0.0.1). To allow external access, edit the “c:\oshmi\conf\nginx_access_control.conf” file to add the desired IP addresses. You can do this to test access on tablets or cell phones. To open the Screen Viewer on a remote device, enter the URL http://w.x.y.z:51909/htdocs/screen.html (replace w.x.y.z by the server IP address) in a compatible browser (Chrome, Firefox, Safari or Opera). It is possible to change the HTTP port, enable HTTPS, add client certificates and enable user auth by tampering the Nginx configuration.
That’s it: following these simple instructions you should easily have a running system. The next step is to learn how to configure the system: a matter for the next articles.
For free assistance on OSHMI, professional support, managed cloud hosted SCADA service, partnerships, or customization of applications for device manufacturers, please contact me on LinkedIn https://www.linkedin.com/in/ricardo-olsen/.
The Open Substation HMI (OSHMI) is a modern open source HTML5 based HMI conceived from the ground up for substation operation, even though it can for sure be used in any other automation field such as industrial, building, IoT, etc.
In this series of articles, I will cover many aspects of the usage of the software: the installation, the configuration of point databases and protocols, the creation of graphics, scripting, etc. Let’s begin with some common use cases for the system.
OSHMI is modular and flexible enough that it can be used in many different ways. The system is composed of three modules that can be separated or joined as desired:
The protocol driver
The real-time web server
The client user interface
For example, for local substation control, it is possible to use a single PC with all three modules integrated. For a Control Center application, you can use 2 redundant servers with the protocol driver and real-time web server modules, and as many client PCs as needed with just the user interface part. It is also possible to have the protocol driver next to the controlled process, the real-time web server on the cloud and the client interface on a mobile device (phone, tablet, etc.). Learning to configure and combine these modules you can cover many use cases, taking into consideration cost and performance of server and client devices, security requirements, bandwidth and communication channel characteristics, locations for operation, etc.
For an IoT scenario, it is possible to use a protocol converter, if necessary to cover all the needed protocols, and hosting all the system in the cloud to be accessed securely from anywhere.
The use of the Nginx HTTP server makes it simple to secure client/server communications by the possibility of using HTTPS, user authentication, and client certificates. Other web servers as Apache can be customized and the real-time web server module can run also on a Linux OS if desired.
The embedded database backend is SQLite based, but it is possible with some scripting to forward historical data to a MySQL, MS SQL Server, PostgreSQL, InfluxDB, or other SGBD for a more robust backend if necessary to store big quantities of data (more than 20GB) or when there will be many clients accessing historical data simultaneously (more than 10).
In short, the OSHMI system allows for a great deal of flexibility and customization. The open source characteristic, the use of web standards and the generally available subsystems permit almost any type of customization necessary to cover many use cases effectively and at the same time minimizes costs.
For free assistance on OSHMI, professional support, managed cloud hosted SCADA service, partnerships, or customization of applications for device manufacturers, please contact me on LinkedIn https://www.linkedin.com/in/ricardo-olsen/.
It is a regular task of those who work with automation systems, SCADA, etc., to configure the data exchanges between the devices, using communication protocols.
Often, these integrations between client and server devices are not easily obtainable.When a problem occurs, there is always a question of whether the cause is on the client or the server.In these cases, you can use third-party tools to simulate client and server systems, log communications so you can better analyze the problem.
In this article, I present some useful tools to perform tests and simulations of some communication protocols.There are many commercial tools for this purpose in the market, like ASE 2000 and Triangle Test Harness, but I will focus only on those that can be obtained free of charge and allow continued use without that typical 30-day limit of use.
This tool is part of the Opendnp3 project, a very complete and excellent quality open source DNP3 protocol implementation.
The simulator allows you to do both the client and server roles.Protocol or TCP variants can be configured.You can create multiple devices.Quality values and bits can be edited for the generation of events in the protocol.
The logs produced are quite detailed and easy to understand, presenting separately the levels of binding, transport, and application.
This software simulates an IEC60870-5-104 protocol server.
You can add point by point to be made available by configuring information type, ASDU address, transmission cause, object address, and value.Timed simulation of values can be made or can be changed manually.The point database can be saved and reloaded later.
Last but not least, Enilit CMS is a complete protocol gateway software.This is without a doubt the best and most powerful free protocol testing tool available. The only limitation of the demonstration version is that after 12h of continuous use the gateway stops to distribute data, needing to be restarted to resume distribution.
Easy to use, Enilit CMS allows you to add, without limits, master and slave ports for the available protocols.The data acquired by one protocol can be distributed by others, combined as desired.
The slave protocols are IEC60870-5-101 / 104, DNP3 Serial and SPA-Bus.The master protocols are IEC61850, IEC60870-5-101 / 103 / 104, DNP3 Serial / TCP, Modbus Serial / TCP and SPA-Bus.Data simulators are also available.
All settings can be changed online, without restarting the system.
The quality of implementation of the protocols is excellent, with international certifications.The logs are very complete and detailed.
To obtain a download link of this software request it here:
É tarefa regular de quem trabalha com sistemas de automação, SCADA, etc., configurar as trocas de dados entre os dispositivos, utilizando os protocolos de comunicação.
Muitas vezes, estas integrações entre dispositivos clientes e servidores não são facilmente obtidas. Quando ocorre algum problema, fica sempre a dúvida de se a causa está no cliente ou no servidor. Nestes casos, pode-se recorrer à ferramentas de terceiros para simular os sistemas clientes e servidores, registrar logs das comunicações para poder então ter melhores condições de analisar o problema.
Neste artigo, apresento algumas ferramentas úteis para executar testes e simulações de alguns protocolos de comunicação. Existem muitas ferramentas comerciais para esta finalidade no mercado, tipo ASE 2000 e Triangle Test Harness, mas vou concentrar apenas naquelas que podem ser obtidas gratuitamente e permitem a utilização continuada sem aquele típico limite de 30 dias de uso.
Esta ferramenta é parte do projeto Opendnp3, uma implementação open source do protocolo DNP3 bastante completa e de excelente qualidade.
O simulador permite fazer tanto a função de cliente como a servidor. Podem ser configuradas as variantes TCP ou serial do protocolo. É possível criar múltiplos dispositivos. Podem ser editados valores e bits de qualidade para a geração de eventos no protocolo.
Os logs produzidos são bastante detalhados e de fácil compreensão, apresentando separadamente os níveis de enlace, transporte e aplicação.
Este software simula um servidor do protocolo IEC60870-5-104.
É possível adicionar ponto por ponto a serem disponibilizados, configurando tipo de informação, endereço de ASDU, causa de transmissão, endereço de objeto e valor. Pode ser feita uma simulação temporizada de valores ou estes podem ser alterados manualmente. A configuração de pontos pode ser salva e recarregada posteriormente.
Por fim, mas não menos importante, Enilit CMS é um completo software de gateway de protocolos. Esta sem dúvida é a melhor e mais poderosa ferramenta gratuita para testes de protocolos disponível. A sua única limitação do modo demonstração é que após 12h de uso o gateway para de distribuir dados, necessitando ser reinicializado para retomar a distribuição.
De fácil utilização, o Enilit CMS permite acrescentar, sem limites, portas mestres e escravas para os protocolos disponíveis. Os dados aquisitados por um protocolo podem ser distribuídos por outros, combinados conforme desejado.
Os protocolos escravos são: IEC60870-5-101/104, DNP3 Serial e SPA-Bus. Os protocolos mestres são: IEC61850, IEC60870-5-101/103/104, DNP3 Serial/TCP, Modbus Serial/TCP e SPA-Bus. Simuladores de dados também estão disponíveis.
Todas as configurações podem ser alteradas online, sem reiniciar o sistema.
A qualidade da implementação dos protocolos é excelente, com certificações internacionais. Os logs são bem completos e detalhados.
Para obter um link para download deste software me solicite aqui nos comentários ou por mensagem particular.
Depois dos horrores passados no episódio WannaCry, que atingiu mais de 200.000 sistemas em 150 países, todos nós fizemos o dever de casa e atualizamos os sistemas operacionais dos sistemas críticos e agora estamos protegidos, certo?
Bem, é certo que 100% de segurança não existe, mas parece que devido à notoriedade do ataque WannaCry, o bug no sistema de gerenciamento AMT dos processadores Intel® para máquinas corporativas passou quase despercebido. Muitos não atentaram para a gravidade e extensão desta vulnerabilidade e não tomaram nenhuma providência, deixando desprotegidos servidores, notebooks, máquinas desktop corporativas e até mesmo sistemas SCADA que executam neste tipo de hardware.
A tecnologia Intel® AMT / IME (Active Management Technology / Intel® Management Engine) permite fazer o gerenciamento total remoto de computadores. Esta funcionalidade é direcionada para o mercado corporativo e não para produtos de consumo comum. Computadores de diversos fabricantes renomados possuem este sistema.
Quando está habilitado (default na maioria dos sistemas) o gerenciamento remoto AMT, o computador pode ser facilmente controlado através da rede, independente do sistema operacional, pois o AMT executa por fora do sistema operacional e por fora do processador principal! O AMT pode ser acessado quando executando SETUP, em standby ou até mesmo com a máquina desligada (estando plugada na rede elétrica)!
Foi descoberto que ao autenticar para fazer o acesso remoto, basta enviar a uma string vazia (tamanho zero) na resposta de requisição de autenticação e o acesso é liberado! A esta vulnerabilidade foi atribuído o nome “Silent Bob is Silent”.
O que fazer?
Desabilite o AMT! Entre no SETUP da máquina e procure por alguma opção como AMT, VPRO, ISM, SBT, Management, Gerenciamento, etc. Se encontrar, desabilite! Outra opção é tentar digitar CONTROL+P durante a inicialização para acessar o menu do AMT. Se pedir para entrar com senha utilize “Admin”, ao solicitar o cadastro de nova senha coloque uma que tenha pelo menos 8 caracteres, com letra maiúscula e minúscula, número e caractere especial, e repita a senha, na sequência desabilite o AMT pelo menu.
Teste as portas TCP 16992-16995 mais a 623 e 664, por exemplo com o nmap do Linux: nmap -p16992,16993,16994,16995,623,664 ip_da_maquina_testada. Se alguma porta estiver aberta, provavelmente o AMT estará habilitado. Procure novamente opções para desabilitar no SETUP da máquina. Se não encontrar, consulte o manual do produto e/ou o site do fabricante.
Execute o software “Intel® Management and Security Status” no Windows. Se aparecer a mensagem “Ativo” significa que o AMT ainda está ativado. Procure novamente desabilitar.
Vários fabricantes já lançaram correções de firmware para diversos modelos de computadores. Verifique no site do fabricante. Com a correção de firmware, é possível utilizar o gerenciamento remoto de forma segura, mas não for usar é melhor deixar o AMT desabilitado.
Não se tem notícia de que este problema tenha sido explorado até o momento (23/maio17), mas note que a ferramenta EternalBlue utilizada pelo WannaCry foi divulgada em 14 de abril e o ataque se deu logo em 12 de maio. O problema do AMT foi divulgado no início de maio, sendo que o ataque é muito simples, a qualquer momento pode ser explorado. Máquinas vulneráveis expostas na Internet podem até mesmo ser encontradas usando o site Shodan!
“There is no such thing as information overload.
There is only bad design.” Edward Tufte
This article aims to describe modern techniques for designing and developing human-machine interfaces (HMIs), in order to obtain improvements in the results of the process operation. The concepts apply to any SCADA system in any type of industry.
The concepts presented here are based on the research and recommendations on User-Centered Interfaces in SCADA systems made by the ASM Consortium, in the book “The High Performance HMI Handbook” by Hollifield et al. (ISBN-10: 0977896919), in the guidelines of the ANSI / ISA101.01-2015 standard (Human-Machine Interfaces for Process Automation Systems), in my investigation of the fundamentals of user interfaces area and in the practical experience of adapting this methodology to the remote control operation of Power Transmission Substations.
What you and your company can gain from this? According to a scientific test developed by the ASM Consortium, a User-Centered Interface compared to a traditional interface achieved the following results:
Problems were detected by the operators 5 times more, before the first alarm.
36% Gain in success rate in completing the proposed operations.
Operators completed the tasks 41% faster.
These are extraordinary gains that translate directly into financial benefits, safety, and quality of operation, please note that these results are obtainable just by redesigning the HMI, there are no other investments.
Of course, the results can vary greatly from case to case, but the benefits are quite obvious once conceived, implemented, tested and put into practice the new interface. In the practical case that I implanted, the new interface obtained an index of more than 80% of approval from the operators, which is extremely significant for the environment of the electric sector where the resistance to the change is notorious.
The importance of the subject is such and the results so concrete that it has motivated the creation of the ISA101 standard. The standard sets out recommendations and best practices that cover the entire lifecycle of the HMIs. The ISA101 standard aims to:
Provide guidance on the design, implementation, operation and proper maintenance of HMIs that result in a safest, most effective and most efficient process control under all operating conditions.
Improve the operator’s ability to detect, diagnose and respond appropriately to abnormal situations.
According to ISA101, Situational Awareness is classified into three levels:
Level 1 – Be aware of what is happening in the process.
Level 2 – Understand the current state of the process.
Level 3 – Understand what should be the probable state of the process in the future.
One of the fundamental characteristics of User-Centered Interfaces is to empower the operator to precisely understand the present situation and to be in a good position to predict the state of the process in the near future and, thus, to have a more preventive action on the process and no longer simply respond to alarms. This is only possible by providing information, in the form of suitable visualizations, in context to the operators, when they need it, and not simply reproducing on the screen the P & ID or single-line diagrams with scattered numbers representing process measurements (traditional methodology allows reaching only Level 1 of Situational Awareness).
Structure and navigation
It is essential that the HMI be always designed with the tasks performed by the operators in mind. So there is no magic formula to create an HMI, but rather a course to pursue using some directions and guidelines as provided here or in the ISA101 standard. For each case, the list of tasks that the operators perform must be elaborated, later studied and from this point on, to think about the structure and then the visualizations. For this, some methodology can be used, for example, GDTA (Goal-Directed Task Analysis).
Two very important aspects of the efficiency of the HMI are the hierarchical structuring of the screens and the consistency of navigation.
It is recommended an organization structured in levels:
Level 1 – Overview or Area Wide Display: This display presents an overview of the general state of the system, and should include the visualization of the main functions that must be monitored by the operator, specifically the main indicators of the situation, quality, production, and safety, as well as systemic alarms. This high-level display is usually shown on the video wall when available. For example, in the case of the substation remote control, it could be the display with the systemic view, that is, with the situation of the interconnection lines between the substations. If there is load and/or voltage control, bar graphs of the largest deviations and trend graphs built into the screen could be shown so that the future condition can be glimpsed and preventive action can be taken to avoid violations of the established limits.
Level 2 – Process Unit or Facility Control Displays: are the set of displays, one for each control unit. For example, in the case of the electrical sector, they would be the displays of each substation. In this, it should be shown the situation of the main processes of the unit, also with the main measurements in visualization in the analog form and graphs of tendencies. These should be the displays that should be created first.
Level 3 – Process Detail or Detailed Information Displays: For each unit, it shows in detail the operation of each process in the unit. It can also represent the state of the equipment that makes up the process or facilitates the execution of specific tasks. In the case of substations, it could be a detailed transformer screen, ancillary services or to support the restoration process.
Level 4 – Process Unit Support or Auxiliary Information Displays: displays that present detailed information on equipment status and instrumentation, as well as help screens, operating instructions, diagnostics, etc. E.g.: supervisory and control architecture screens, showing the health and status of equipment and the status of communications links.
Navigation must be consistent so that the operator is never left without guidance. There must be a clear and fast way to navigate the four hierarchical levels, the links should be positioned consistently and be shown at what level you are at the moment. As a reference, you should be able to reach any screen in up to three clicks in at most 5 seconds.
The use of colors
The proper usage of colors in HMIs is one of the most important factors that define the high-performance graphics recommended by ANSI / ISA101.01-2015 and several other authors.
The use of colors should be limited, because too much color makes the visualization confusing to the operator, especially in stressful situations. Alarm colors should be reserved for this function only to make it easier to identify what is most important at the right time.
The normal operating situation should be represented serenely, basically with 2D, with limited contrast and few colors. The use of 3D, complex textures, shading, gradients and excessive contrast should be avoided as they overload the visual processing of the brain, causing fatigue and slowness in understanding the situation. Bright colors and animations should also be avoided except for alarm situations.
Colors should not be the only way to represent information. This is necessary because of the fact that about 10% of men have some visual impairment for color identification. For example, it is not recommended to differentiate the type of the measurements only by the colors, it is advisable to place the unit next to the measurement. The open and closed circuit breaker representation (in the case of substation control systems) should not only be made by color: the open circuit breaker should be hollow, for example, and the closed circuit breaker should be filled to facilitate differentiation.
The background color recommended by the vast majority of authors is light gray (close to RGB 200, 200, 200). This color is considered to provide adequate contrast and causes little visual fatigue when harmonizing with a well-lit environment. However, I believe it is possible, while not ideal, to also apply many of the high-performance graphics concepts even using other backgrounds, such as black, dark blue, and white.
The forehead color should provide an adequate contrast to the background, but not excessive, it can usually be in dark gray shades, with variations in the thickness of the lines and size for the texts according to the importance of the represented objects. Other colors may also be used, but restricted to a single hue, for example, in a pastel (not bright) shade of green or blue.
For alarms, it is suggested to use red, yellow, orange and violet according to priorities. Also for alarms, color should not be the only form of representation and should be combined with shape (form) and text (triple coding).
The use of colors should be efficient, consistent and documented for all functions, across all displays. In this way the operators’ learning curve becomes quite smooth, that is, in a short time, the operators learn to use the system properly. On the other hand, graphs made without a criterion, require the operators to take months or even years to get accustomed and to be able to process minimally the data presented in the displays, and even after this time, they will have their working memory overloaded, which can cause delay and error in decision making.
The form of representation of measurements in the HMIs is an aspect that almost always presents opportunities for significant improvements.
A measured value represented only by the number on the screen causes the need for the operator to mentally process the value to know if the value is high/low, erroneous, increasing/decreasing, or if it is close to entering the alarm range. Notice that it is common that established limits can only be checked by accessing the point data by opening the faceplate info dialog. This will burden the working memory and reduce the cognitive ability of operators. With experience, operators can become more efficient at this kind of task, but will always be overloaded in some way. Note that this overcharge is multiplied by the number of measurements presented on the screen.
To facilitate the rapid identification of the quality of measurements, it is recommended that at least the most critical measurements of the process be represented in the analog form.
See the figure below of the Star Trek series and compare with the numerical representation:
Dashboards allow for a much faster identification of the health of a process and are especially recommended in the charts belonging to levels 1 and 2 of the navigation hierarchy.
Some useful types of representation are:
Vertical bar graph;
Horizontal bar graph;
Web or radar graph.
Pizza and donut graphics are not recommended for more than 2 measurements on the same chart as they do not easily allow comparison of quantities.
Gauge graphics are also not ideal because they take up a lot of space. They are often marketed because they mimic reality (skeuomorphism), with the unnecessary use of shading, reflections and bright colors.
Another highly recommended form of representation is trend charts. These are very useful as they allow to identify whether the measurement is stable, or is approaching the alarm range and how quickly. Thus, the operator can act preventively in order to avoid violations and to make the process more optimized, economical and safe. These graphs should be plotted directly on the screen. A plot utility is not a substitute for this functionality.
For purely numerical representation, it is important:
A not too prominent text color (reserve bright colors only to represent failures or alarms);
A sans serif font, with monospaced numbers that renders anti-aliased;
A size and contrast adequate for good readability;
The representation of the unit of measurement next to the value in a faded color;
That positioning be made in a coherent order;
To avoid showing unnecessary decimal places;
To use symbols to represent flow direction and increase/decrease in value.
Life Cycle and Documentation
Establishing a Life Cycle for HMIs is an important definition of the ISA101 standard. The Life Cycle aims to regulate all aspects of HMIs from the creation, implantation, operation and even maintenance. The Life Cycle comprises:
System Standards: contains the rationale for the elaboration of the HMIs.
Design: definition of functional, hardware and software aspects of HMIs.
Implementation: the creation of the HMI in the target platform and put into action.
Operation: production phase, including maintenance and change management.
Continuous Work Process: audit procedures and maintenance of HMIs.
The System Standards are composed of the HMI Philosophy Document, the HMI Style Guide, and the Toolkit. These components should be elaborated or revised whenever a new system is created or when significant changes in processes or systems occur.
The HMI Philosophy Document should contain the considerations and principles to be followed in the HMI projects, bearing in mind the human aspects, best practices and functional requirements, all independently of the supplier’s software platform.
The Style Guide goes into the functional details of the implementation and operation of the HMI, showing how the interface components should be created and how they work, and taking into account the specificities of the controlled process. This document should also be independent of the target platform. Note that this part of documentation can be reused in case of change of supplier or exchange/upgrade of the system platform. It can also be used to elaborate the specification of the HMI system in new projects.
The Toolkit is the implementation of the basic elements, objects, and templates, already on the target platform, that will serve to compose the HMI displays.
A well-grounded, thoughtful, detailed System Standards will be the foundation that can avoid many problems and save a lot of time in the remaining phases of the HMI life cycle.
In the HMI Design stage the following tasks must be performed:
Functional, user and task requirements. It aims to identify the activities that will be carried out through the HMI.
HMI System Design. Its objective is to define the HMI platform, interfaces, communication and controls to be performed.
Console Design. Defines all hardware, software, and furniture to use in the solution.
Display Design. Identifies the required displays, their content, and the navigation and hierarchy schemes.
The Implementation stage is divided into the following activities:
Build of displays, databases, alarms and configurations.
Build Consoles: physical construction of the operating consoles.
Tests: tests of the displays and systems before deploying in a production environment.
Commissioning: tests in operation in the production environment.
Training and certification of users. It is important that users are presented with the philosophical and standardization documents so that they understand the foundations of the HMI construction.
The Operation stage of the HMI comprises:
In Service: the HMI system in operation.
Maintenance: keeping the HMI always functional, correct, updated and optimized.
Decommission: management of partial or total deactivation of HMIs.
The Continuous Work Process is composed of:
Management of Change: considers the impacts of changes to be introduced in processes, tasks, and functional requirements. It must guarantee the safety and effectiveness of the operation of the process.
Audit: verification that the HMIs are being managed and maintained according to established standards.
Validation: conference that the HMI’s meet the functional requirements, the effective accomplishment of operational tasks and the conformity of human / ergonomic aspects.
With this article, I hope to have contributed to spreading the modern methodology of HMI design, which can bring enormous benefits in safety, productivity and cost savings in the operation of processes from all types of industries.
Electrical Engineer, Master’s Degree in Engineering (Federal University of Rio Grande do Sul – UFRGS/Brazil).
Areas of expertise: SCADA/EMS systems, historian systems, communication protocols, High-Performance HMI, substation automation, control centers, cloud systems, information integration, and visualization.
“A designer knows he has achieved perfection not when there is nothing left to add,
but when there is nothing left to take away.”
Antoine de Saint-Exupery
O estabelecimento de um Ciclo de Vida para as IHM’s é uma importante definição da norma ISA101. O Ciclo de Vida pretende regrar todo os aspectos das IHM’s desde a criação, implantação, operação e até a sua manutenção. O Ciclo de Vida compreende:
Padrões e Documentação do Sistema: contém a fundamentação para a elaboração das IHM’s.
Projeto: definição dos aspectos funcionais, de hardware e software das IHM’s.
Implementação: criação da IHM na plataforma alvo e posta em marcha.
Operação: fase de produção, inclui a manutenção e gerenciamento de alterações.
Processo Contínuo de Melhorias: procedimentos de auditoria e manutenção das IHM’s.
Os Padrões e Documentação do Sistema são compostos pelo Documento de Filosofia de IHM, pelo Guia de Estilos da IHM e pelos Toolkits. Estes componentes devem ser elaborados ou revisados sempre que um novo sistema for ser criado ou quando alterações significativas nos processos ou sistemas ocorrerem.
O Documento de Filosofia da IHM deve ser elaborado com as considerações e princípios a serem seguidos nos projetos de IHM, considerando os aspectos humanos, melhores práticas e requisitos funcionais, tudo isto em forma independente da plataforma de software do fornecedor.
O Guia de Estilos entra nos detalhes funcionais de implementação e funcionamento da IHM, mostra como devem ser feitos e como funcionam os componentes da interface, levando em conta as especificidades do processo controlado. Este documento também deve ser independente da plataforma alvo. Note que esta parte de documentação pode ser reaproveitada em caso de mudança de fornecedor ou troca/upgrade de sistema. Pode ser aproveitada também para elaborar a especificação do sistema de IHM em novos projetos.
O Toolkit é a implementação dos elementos básicos, objetos e templates, já na plataforma alvo, que servirão para a comporem as telas de IHM propriamente ditas.
Um trabalho bem embasado, criterioso e com atenção aos detalhes nesta parte de fundamentação, pode evitar muitos problemas e economizar muito tempo no resto do ciclo de vida da IHM.
Na Fase de Projeto da IHM devem ser feitas as seguintes tarefas:
Requisitos funcionais, do usuário e das suas tarefas. Visa identificar as atividades que serão desempenhadas através da IHM.
Especificação do Projeto da IHM. Tem por objetivo definir a plataforma de IHM, interfaces, comunicação e controles a serem realizados.
Projeto das Consoles. Define toda a parte de hardware, software e mobiliário a serem empregados na solução.
Projeto das Telas. Identifica as telas necessárias e os esquemas de navegação e hierarquia.
A Fase de Implementação é dividida nas seguintes atividades:
Elaboração das Telas, bases de dados, alarmes e configurações.
Montagem das Consoles: construção física das consoles de operação.
Testes: testes das telas e sistemas antes de colocar em ambiente produção.
Comissionamento: teste e operacionalização já em ambiente de produção.
Treinamento e certificação dos usuários. É importante que aos usuários sejam apresentados os documentos filosóficos e de padronização para que entendam como está fundamentada a construção da IHM.
A Fase de Operação da IHM compreende:
Colocação em Serviço.
Manutenção: manter a IHM sempre funcional, correta, atualizada e otimizada.
Desativação: gestão da desativação parcial ou total das IHM’s.
O Processo Contínuo de Melhorias é composto de:
Gestão de alterações: considera os impactos das alterações a serem introduzidas nos processos, tarefas e requisitos funcionais. Deve garantir a segurança e efetividade da operação do processo.
Auditagem: verificação de que as IHM estão sendo gerenciadas e mantidas de acordo com os padrões estabelecidos.
Validação: conferência do atendimento aos requisitos funcionais, da realização efetivas das tarefas operacionais e da conformidade dos aspectos humanos/ergonômicos.
Com este artigo encerro esta série. Espero ter contribuído para difundir esta metodologia tão importante que pode trazer enormes benefícios em segurança, produtividade e economia na operação de processos.