Opc ua server for linux

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

An OPC UA Server Implementation in C for Linux and Windows that encapsulates an ODBC-supported database

17zhangw/OPC-UA-ODBC-Server

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

A running OPC UA Server (Release 1.03) that was implemented in C for both Windows and Linux distributions. The OPC UA Server runs with binary encoding over TCP. This specific implementation of the OPC UA Server exposes through the address space a set of ODBC functions. In other words, the current implementation encapsulates an ODBC-supported database abstractly through method calls rather than directly exposing the internal database structure and internal data directly in the address space.

This server was originally developed as part of a year-long research project for an academic course (AP Research). This particular version of the source code is released with explicit permission from iData Inc. for which I am grateful for. However, this repository has been and is no longer actively maintained since August 2017 due to contractual clauses between myself and iData Inc. concerning this codebase.

This repository contains the following pieces of information. Although the Visual Studio 2015 and Netbeans (for Ubuntu/CentOS) projects have been distributed in this repository, the projects still require tweaking to account for library search paths and other more system-specific configurations. The codebase has been separated into various folders depending on the specific function of that particular code within the larger context (i.e AddressSpace infrastructure are in the AddressSpace folder, OPC UA function definitions and database methods are in the Functions folder).

1. README.md
2. Visual Studio 2015 Project
3. Netbeans C/C++ Project
4. Source Code in Subfolders

At the current moment, the following functions are supported. For allowing the end-user to selectively target an ODBC driver, both wchar_t and multibyte char functions are exposed. The prefixing to functions mirrors the convention surrounding ODBC with the ‘W’ suffix indicating Unicode Driver and ‘A’ indicating ANSI Driver. Although these functions have been tested primarily against SQL Server 2014 and 2017, other databases will work, although minor adjustments may be necessary for optimization purposes and/or to improve compatibility.

The currently publicly exposed functions are:

1. SQLConnect
2. SQLSetCommit
3. SQLCommit
4. SQLDisconnect
5. SQLAllocHandle
6. SQLCloseHandle
7. SQLResetParamsHandle
8. SQLFreeHandle
9. SQLExecDirect
10. SQLInsert
11. SQLUpdate
12. SQLDelete
13. SQLSelect
14. SQLFetch
15. SQLPrepare
16. SQLBind
17. SQLExecute

The privately depended upon functions are:

1. SQLColumns
2. SQLBindCol
3. SQLDescribeCol
4. SQLFetch
5. SQLGetInfo (SQL_DYNAMIC_CURSOR_ATTRIBUTES1)
6. SQLNumResultCols
7. SQLFetchScroll
8. SQLGetDiagRec

Notes/Caveats

• Storing BINARY data into the database is supported through the functions provided. However, the BINARY data when passed into the function as an OPC UA parameter must be encoded in Base64 without any line breaks.
• All publicly exposed functions require the first parameter to be an UINT32 value that was passed into SQLAllocHandle.
• Most publicly exposed functions accept a second parameter that must be JSON-encoded.
• The functions return up to a maximum of 3 values — with the first parameter indicating success/failure of the database operation, the second parameter representing a textual JSON-encoded result if applicable, and the third result indicates the number of affected rows.
• The JSON definitions can be accessed via querying the description attribute of the Argument or in UASpace/InitializeCustom.c

• Address Space Node IDs and Namespace are defined in Definitions/id_opcua_db_def.h
• Server Information configuration in Definitions/id_opcua_serverinfo.h
• Parameters concerning communication (including PKI) in Definitions/id_opcua_comm.h
• By default, the server listens on port 4840 and uses PKI for verification of client certificates

Sample Function Call Sequences

SQLAllocHandle() . SQLInsert() . SQLUpdate() . SQLDelete() . SQLSelect() SQLFetch() SQLFetch() SQLFreeHandle() 

SQLAllocHandle() SQLPrepare() SQLBind() . SQLBind() SQLExecute() SQLResetParamsHandle() SQLBind() SQLExecute() SQLFreeHandle() 

SQLConnect() SQLSetCommit() . (various operations) SQLCommit() SQLDisconnect() 

1. OpenSSL 1.0.2j with development headers
2. OPC UA UA-AnsiC Stack
3. cJSON library by DaveGamble
4. ODBC in addition to ODBC headers (sql.h, sqlext.h)
5. Various system libraries

Please refer any contact to 17zhangw@gmail.com with ‘OPC UA’ in the subject header.

About

An OPC UA Server Implementation in C for Linux and Windows that encapsulates an ODBC-supported database

Источник

Шлюзы промышленных протоколов обмена на Linux. Собери сам

Я занимаюсь разработкой, внедрением и эксплуатацией систем автоматического управления технологическими процессами (АСУ ТП). Поначалу работал со SCADA-системами. Потом довольно быстро переключился на работу с протоколами обмена промышленных устройств. Как самостоятельное написание драйверов, так и настройка систем сбора данных. В настоящий момент моя работа проходит атмосфере Modbus-ов, МЭКов-101/104-х, ОРС и прочих протоколов.

Рис. 1. Многообразие протоколов обмена, используемых в АСУ ТП

Кратко о том, как устроена типичная система сбора данных (Немного упрощенно).

Рис. 2. Система сбора данных

Специальное ПО, называемое OPC-сервером ведёт опрос устройств, подключенных к интерфейсу RS-485. OPC-сервер является своего рода прослойкой между SCADA-системой и устройствами, переводя язык на котором общаются устройства в язык, понятный SCADA-системе. Преобразователь Ethernet/RS-485 служит для преобразования TCP/IP-пакетов в пакеты, которые ходят по физической среде RS-485.

Эта схема имеет ряд недостатков:

1. Установим, например, в ОРС-сервере таймаут ожидания ответа 200 мс. В идеальном случае, когда пакеты в Ethernet ходят без задержек, обмен с устройствами идёт с хорошей скоростью (интенсивностью). Но если пакет, содержащий ответ, задерживается, например, на 300 мс (это больше таймаута ожидания ответа 200 мс), то ОРС-сервер считает, что ответ на запрос не пришел и отправляет следующий запрос. В это время приходит ответ на предыдущий запрос, но ОРС-сервер думает, что это пришел ответ на текущий запрос и передаёт неправильные данные наверх. Как результат данные на АРМе «скачут». Чтобы уйти от таких ситуаций установим таймаут больше. Возьмём с запасом — 3000 мс. Если ответ приходит раньше 3000 мс, то оставшееся время не ждём, переходим к следующему запросу. Пока всё идёт хорошо, но стоит нескольким устройствам перестать отвечать, как образуются задержки по 3000 мс на каждое устройство. Время опроса увеличивается.
2. Большинство протоколов, используемых в АСУ ТП (Modbus, счетчики э/э) основываются на последовательном опросе одних и тех же параметров. Учитывая, что большую часть времени значения параметров остаются неизменными, сеть передачи данных используется для передачи одного и того же. Это нерационально, если среда передачи GPRS, и трафик стоит денег. Кроме того, в среде передачи GPRS задержки прохождения пакетов могут достигать нескольких секунд. Зачем тратить время и ресурсы для передачи одного и того же?

В общем какие-то аппаратные шлюзы есть и в немалом количестве. Но в виде готовых неделимых решений. Всё в одном. И это мне не особо нравится. Понадобился мне когда-то шлюз, преобразующий протоколы счетчиков СЭТ-4ТМ в OPC UA с шестью портами RS-485 и двумя Ethernet. У одного производителя есть шлюз с поддержкой нужных протоколов обмена, но мало портов RS-485, у другого есть нужное количество портов RS-485, но нет двух портов Ethernet. У третьего есть два порта Ethernet, но нет всех протоколов обмена. У четвёртого есть почти всё, но нет OPC UA, имеющиеся на борту МЭК-60870-5-104 или ModBus-TCP требуют ОРС-сервера для этих протоколов.

А как бы было замечательно: купить контроллер или мини-ПК с ОС у одного производителя. Купить ПО для контроллера у другого. Если одного производителя ПО не поддерживает что-то, докупить что-то из ПО у другого, объединить между собой компоненты ПО через стандартный программный интерфейс. Казалось бы, вот оно светлое будущее!

Вот поэтому шлюзы протоколов применяются реже чем связка «ОРС-сервер и «Преобразователь Ethernet в RS-485»» — из-за их неделимости на компоненты.

Одна из причин, почему мало развиты SCADA для Linux: SCADA есть, протоколов обмена в ней поддержано мало, а ОРС-серверов для связи с оборудованием нет. SCADA оставляет интегратора один на один с железом.

Читатель уже может задавать вопрос: Что можете предложить? Что уже есть? Есть OPC UA серверы для Linux для следующих протоколов:

• МЭК 60870-5-104;
• МЭК 60870-5-101;
• Счетчики Меркурий 230, 231, 233, 234, 236;
• Счетчики СЭТ-4ТМ, ПСЧ-3ТМ, ПСЧ-4ТМ;
• Счетчики Энергомера;
• SNMP;
• MQTT;
• Счетчики Меркурий 200.

OPC UA серверы и преобразователь работают на архитектурах x64, ARMv7 и AARCH64.
Таким образом, для аппаратной части можно использовать как проверенные временем решения на базе мини промышленных компьютеров, так и всевозможные «raspberry pi совместимые» ARM миникомпьютеры. Как производится установка и настройка ПО с примерами можно почитать здесь или здесь.

В общем виде структура комплекса выглядит так:

Система обладает масштабируемостью. Используются компоненты необходимые только для решения текущей задачи.

С использованием OPC UA сервера наша схема преобразуется:

У нас получилось следующее:

• OPC UA сервер собирает данные с устройств по RS-485 без больших задержек между запросами;
• Данные в SCADA выдаются по нескольку штук в одном TCP-пакете по изменению;
• К OPC UA серверу можно подключить несколько одинаково настроенных АРМов. Пригодится, если нужно дублирование.

Источник