Промышленные сети SAFE

[Михайло]

Ну и как же тогда работает safety-сеть?

[Степа]

Если пакет не дошел, то (в моем упрощенном представлении) процесс стопится и достигается безопасное состояние.

Абонент Б /тюрьма/ узнает за недоставку только в одном случае: его перед этим известили, что будет важное сообщение. Обычно так только политики поступают или в системе нелегальной связи. В нормальной жизни если сообщение есть, то оно передается. Таким образом имеем недиагностируемый отказ: недоставку вовремя жизненно важного пакета.
Скажем, в достаточно часто используемом протоколе TCP предусмотрены квитанции доставки пакета, если квитанции не было - пакет повторяется. Три раза не пришла квитанция - диагностируется обрыв связи. Вот именно на таком принципе и построена гарантированность доставки TCP /UDP такой гарантии не дает - выдал пакет и хоть не рассветай/. Только почему-то никому в голову не приходит назвать TCP - safety-протоколом.

[Василий Иванович]

Михайло, отказать может всё - обычная сеть или безопасная. Вопрос в том, с какой вероятностью. Эта вероятность для безопасной сети не должна превышать определённого в стандарте порога. А достигается комплексом мер, как то квитированием, резервированием, контрольными суммами, проверкой достоверности, таймаутами и т.д. и т.п. Какие-то из этих мер могут присутствовать и в системах обычного назначения, как указал Степа, но в безопасных системах эти меры присутствовать должны.

Вот нашёл ещё одно хорошее описание, в котором затрагиваются вопросы, обсуждаемые в нашем топике. Даже аналогия с заказной почтой есть (я сам офигел, чесслово)! :D

http://www.profibus.com/nc/downloads/do ... YqaT5pj-xg

[Михайло]

Михайло, отказать может всё - обычная сеть или безопасная.

Ну тут такой момент... Отказ безопасен!

[Василий Иванович]

Отказ может быть опасным и безопасным. При безопасном отказе система отключит подачу энергии, перейдя в безопасное состояние. Тем не менее остается вероятнось опасного отказа, когда функция безопасности не сработает. Этот остаточный риск нормируется пороговым значением, соответствующим требуемому уровню безопасности.

[Степа]

Отказ безопасен!

С чего бы это? Давнули стоповую кнопку, но сообщение за то потерялось и это вот - безопасный отказ??!!! Что ж ты тогда называешь опасным отказом?

Этот остаточный риск нормируется пороговым значением, соответствующим требуемому уровню безопасности.

И риск этот с сетевой стоповой кнопкой куда как выше риска с обычной кнопкой хотя бы потому, что обычная кнопка существенно проще сетевой.

[Михайло]

С чего бы это? Давнули стоповую кнопку, но сообщение за то потерялось и это вот - безопасный отказ??!!!

Ну ты как-то односторонне анализируешь. Неужели не существует метода обнаружить недоставку на стороне приемника? ;-)

[Степа]

Неужели не существует метода обнаружить недоставку на стороне приемника?

Не поверишь, но нет. Точнее есть тройка способов:
1. Перед важным пакетом послать пакет-уведомление. Который тоже никто не мешает посеять... Да и время тратится.
2. Связь по расписанию: пакет вовремя не пришел - проблема
3. Телепатия
Лично я ни в одной спецификации, если говорить за промышленные протоколы, еще не видел ни одного из этих способов.

[Михайло]

Хорошо, я не вижу проблемы. Ты "знаешь" три-четыре серьезных протокола и ни одного safe в списке нет.

[Степа]

я не вижу проблемы

Ты видишь суслика? Нет. И я нет. Но он есть! (с)
Если ты не видишь проблемы, то не значит, что ее нет.

Ты "знаешь" три-четыре серьезных протокола и ни одного safe в списке нет.

Ну расскажи мне устройство хоть одного. Я-то могу...

[san]

Отказ безопасен!

С чего бы это? Давнули стоповую кнопку, но сообщение за то потерялось и это вот - безопасный отказ??!!! Что ж ты тогда называешь опасным отказом?

Этот остаточный риск нормируется пороговым значением, соответствующим требуемому уровню безопасности.

И риск этот с сетевой стоповой кнопкой куда как выше риска с обычной кнопкой хотя бы потому, что обычная кнопка существенно проще сетевой.

Не надо считать себя всезнающим. Почему тогда все пользуются этими технологиями, если они ненадежны?
Дело в том, что все девайсы - как датчики, так и устройства безопасности являются интелектуальными, и если они что-то не получили, это тут же считается опасностью, после чего они переходят в безопасное состояние. Если они обестачиваются, или их интелект "сошел с ума", они опять же таки переходят в безопасное состояние. С другой стороны, если датчик подключается по обычным проводам на длинные растояния, и по каким-то причинам кабель оборваля или наоборот коротнул (в вечно безопасном положении) то ещё спорным является вопрос, какое решение более безопасное.
Я встречался с проблемой, что установку не удается запустить, потому что один из сейф датчиков не определился сейф контролером (последний надо ещё научить такому), и считалось что он вышел из строя. Хотя сам датчик Мастером сети (ASi) виделся, и идентифицировался.

[Степа]

Почему тогда все пользуются этими технологиями, если они ненадежны?

Давайте подумаем... Всякие "МММ", "Христианское согласие" и прочие финансовые пирамиды имеют место быть с 1720 года регулярно обрушаясь. В ряде стран даже законодательно запретили деятельность финансовых пирамид. Вопрос: почему люди продолжают упорно лезть в пирамиды как мухи на г..о?
Если вы, уважаемый, такой знающий, то разъясните устройство хоть какой-нибудь сети с ярлычком "safe". Только не воплями "всем известно", "а вы думаете, американцы - дураки?" и прочей демагогией.
Рекламные листочки читать доводилось... Скажем, Сименс вот со своим profisafe даже не скрывает, что safe-уровень запущен поверх стандартного:

Т.е. ничего принципиально нового тут быть не может: если стандартный протокол теряет, например, каждый десятый пакет, то ему совершенно параллельно какой пакет терять. Профибас сам по себе посложнее протокола типа "запрос-ответ", так что добавление в тот цикл еще одной квитанции никак не отразится на надежности. Дополнительное поле контрольной суммы разве что может сыграть свою роль в выявлении ошибочного пакета...

[san]

Дополнительное поле контрольной суммы разве что может сыграть свою роль в выявлении ошибочного пакета...

Вы сами ответили на свой же вопрос. Это один из механизмов, который используется.
Один из уважаемых специалистов, который написал книгу о проектировании безопасных производств в критическом стиле, тоже написал, что Изернет никуда не годится. Судя из его выражений в книге, он до сих пор думает что там работает CSMA-CD.
Степа, Ваш стиль высказывания не терпит других мнений окромя Ваших. Вы можете ошибаться. Для того чтоб что-то критиковать надо в этом что-то разобраться. Я только кусочек зацепил, но не стал бы сразу высказываться что это плохо потому что сложно. Системы часто не запускаются/отказывают не от того, что там микропроцесорные головы в центре, и они сложнее чем релейная автоматика, а потому что плохие контакты.

[Василий Иванович]

Люди, вот вы ругаетесь, а всё оттого, что по моей последней ссылке не сходили. А там написано:

These safety measures include:
 The consecutive numbering of the PROFIsafe messages ("sign-of-life")
 A time expectation with acknowledgement ("watch-dog")
 A codename between sender and receiver ("F-Address")
 Data integrity checks (CRC = cyclic redundancy check)

Using the Consecutive Number, a receiver can see whether or not it received the messages
completely and within the correct sequence. When it returns a message with the Consecutive
Number only as an acknowledgement to the sender, the sender, too, will be assured. Basi-
cally, a simple "toggle bit" would have proven sufficient. However, due to the storage buffers in
some bus components, e.g. switches, a 24-bit counter was selected for PROFIsafe.
In safety technology, it not only matters that a message transfers the correct process signals or
values, the updated actual values must arrive within a fault tolerance time, thus enabling the
respective F-Device to automatically initiate any necessary safety reactions on site, e.g. stoppage
of movement. For this purpose, the F-Devices utilize a watchdog timer that is restarted whenever
a new PROFIsafe message with incremented Consecutive Number arrives.
The 1:1 relationship between the master and a slave facilitates the detection of misdirected mes-
sage frames. Sender and receiver must simply have identification (codename) that is unique in
the network, and can be used for verifying the authenticity of a PROFIsafe message. PROFIsafe
uses an "F-Address" as the sender/receiver- codename.
A cyclic redundancy check (CRC) plays a key role in detecting corrupted data bits. The necessary
probabilistic examination makes use of the definitions within the IEC 61508 that considers the
probability of dangerous failures of entire safety functions. PROFIsafe follows this approach
(Figure 8). According to these definitions, a safety circuit includes all sensors, actuators, transfer elements
and logic processes that are involved in a safety function. IEC 61508 defines overall values for the
probability of failures for different safety integrity levels. For SIL3, for example, this is 10-7/h. For
the transmission, PROFIsafe is allowed a mere 1% contribution, meaning that the permissible
probability of dangerous failures is 10-9/h. This permits suitable CRC polynomials to be deter-
mined for the intended PROFIsafe message lengths. The resulting residual error probability of
undetected corrupted PROFIsafe messages at a maximum bit error probability of 10-2 guarantees
the required order of magnitude. PROFIsafe uses a 24-bit and a 32-bit CRC generator polynomial to
calculate the corresponding 3- or 4-byte signatures. The quality of the chosen CRC polynomials
and the special calculation method is such that PROFIsafe is totally independent of any error

Мне кажется, вполне понятно и доходчиво всё объяснено.

[san]

Почему не ходили, я ходил и в коллекцию доков себе добавил. Как раз о CRC (контрольной сумме) и Степа сказал.
В других сетях могут использоваться другие механизмы. Хотя F-Address похоже у ASi есть. Тольок вот по всем докам, которые мне встречались, по крайней мере беглый просмотр не дал теоретического обзора проблем, которые решаются Safe-алгоритмами и протоколами. Сразу в лоб решения. Может что-то пропустил?

[san]

IEC 61508 address all known failure modes for communication systems, such as software failures in the communication protocols, hardware failures in transmitters, receivers, gateways and routers and sporadic disturbance of the transmission path.
The IEC 61508 introduces the following failure modes:
1. Data corruption
2. Corruption of sender and/or receiver addresses
- Wrong sender and/or receiver addresses
- Multiple receiver addresses (identical addresses on different devices)
- No address match
3. Transmission of data packages at the wrong point in time
- No transmission
- Delayed transmission
4. Wrong sequence of packages
A safety-critical system requires that data can be validated in both a value- and a timedomain.
To determine the validity of safety relevant data, we must have access to enough information related to the data to be able to correctly answer four questions. Under each of these questions I have listed alternative ways to look at the same questions to clearly state what lays beneath the motivation for theses inquiries:
• Are the data I just received from the right sender? Does this arrived data have the right sender-address? Is it right that this device is sending data to me? Am I the right recipient?
• Does the data I just received have the right value? Have the data been corrupted along the way to me? Can I trust the values I just received from my communicating partner?
• Is it correct that I received data at this point in time? Is it too late or too early to receive data now? I expect to receive data now, where is it?
• Does the data have the right sequence number? Have I received this data before? Have I missed some data?
Взял отсюда:

...Там вот этот документ наверное наилучший, хоть база на FF.
http://www.itk.ntnu.no/fag/TTK4545/TTK2 ... rb-UiO.pdf

[san]

По ASi Safe нашел только такую скудную информацию:

Safe data transfer is ensured by means of a dynamic, secure transfer protocol between the safe slaves and the safety monitor. In each cycle, the safety monitor expects a
specific telegram from each slave that changes continuously in accordance with a defined algorithm.

Прилагается ещё картинка, где каждый цикл 4-х битовое значение увеличивается на 1. Может картинка просто пример? Может в алгоритме задается какое-то число инкрементации, иначе как объяснить, что при смене слейва надо об этом сообщить AS-i Safe Монитору.

[Михайло]

 The consecutive numbering of the PROFIsafe messages ("sign-of-life")
 A time expectation with acknowledgement ("watch-dog")
 A codename between sender and receiver ("F-Address")
 Data integrity checks (CRC = cyclic redundancy check)

Итак, значит, 4 принципа:
1. Признак жизни. Последовательное пронумеровывание сообщений.
2. Сторожевой таймер. Ожидание по времени с подтверждением.
3. F-адрес. Позывные имена между отправителем и получателем.
4. CRC. Проверка целостности данных.

[Михайло]

Прилагается ещё картинка, где каждый цикл 4-х битовое значение увеличивается на 1. Может картинка просто пример? Может в алгоритме задается какое-то число инкрементации, иначе как объяснить, что при смене слейва надо об этом сообщить AS-i Safe Монитору.

Это я так и понимаю, что соответствует первому принципу ProfiSAFE.

[Василий Иванович]

Этот остаточный риск нормируется пороговым значением, соответствующим требуемому уровню безопасности.

И риск этот с сетевой стоповой кнопкой куда как выше риска с обычной кнопкой хотя бы потому, что обычная кнопка существенно проще сетевой.

Неверно. Риск отказа сети будет много выше простого провода, это правда. Но этот риск включает себя безопасный и опасный отказы. Риски же опасного отказа тем не менее будут сравнимы, потому что львиная доля отказов сети - диагностируемы, что делает возможным немедленное срабатывание защиты. Главное отличие для клиента, таким образом, будет более частое ложное срабатывание, и для очень многих вполне терпимо. Если же процесс не любит аварийных остановов, тогда применяется резервирование.

[san]

Это я так и понимаю, что соответствует первому принципу ProfiSAFE.

... думаю что даже всем принципам IEC 61508, хотя они перекликакаются с реализацией PROFISafe. Всё вроде логично, но как-то по ASi Safe не много инфы.

[san]

По ASi Safe нашел только такую скудную информацию:

Safe data transfer is ensured by means of a dynamic, secure transfer protocol between the safe slaves and the safety monitor. In each cycle, the safety monitor expects a
specific telegram from each slave that changes continuously in accordance with a defined algorithm.

Прилагается ещё картинка, где каждый цикл 4-х битовое значение увеличивается на 1. Может картинка просто пример? Может в алгоритме задается какое-то число инкрементации, иначе как объяснить, что при смене слейва надо об этом сообщить AS-i Safe Монитору.

Вот что ещё нашёл:

The ordinary AS-i 4-bit protocol is a prerequisite for the use of Safety at Work components. As standard masters and controllers are to be used, a safety protocol is generated by the safe slaves and monitored by a new AS-i component, the safety monitor.
Each safe slave has a 8 x 4- bit code table, which is as individual as a fingerprint, thus making sure that each safe slave transmits a different code. This code is inserted into the normal data message during the 8 AS-i cycles (see figure “safety code sequence in the AS-i message”).

Таким образом последовательность 4-х битных посылок у каждого сейф-слейва своя, и крутится по кругу из 8-ми циклов. Тобишь 32-битный уникальной сейв-код посылается за 8 циклов, а если посылается 0000 или 1111 или ничего или не тот код который ожидался - это и есть ошибка. Я так понимаю так убиваются все 4 зайца:
1. Последовательность соблюдается согласно ожидаемой таблицы (сейф-монитор обучается перед использованием в его составе сейф-слейва);
2. Цикл шины постоянный и циклическим является опрос каждого слейва, отсюда нет посылки - есть ошибка;
3. Идентификация слейва достигается уникальностью 8х4 бит посылкой сейф-слейва
4. Проверка целосности. Вот тут вопрос спорный и требует копания в мат.статистике и теории вероятности. Логично он вроде не нужен. Я думаю так:
- если мы ждем от этого слейва именно 1110 а пришло 1010 (потому что один бит исказился), то это уже опасное событие
- если мы ждем 1110, а слейв отправил 1111(ошибка) а пришло 1110 которого ожидали (один бит исказился) то это уже проблема, так как слейв не отловил опасное событие, но....
....есть ещё бит паритета, и... самое главное, гарантированая реакция монитора - максимум 40 мс, а это как раз 8 максимальных циклов опроса всех ведомых, тоесть один поный цикл перебора 4-х битных частей кода. И очень маловероятно, что все из них исказятся с 1111 (или 0000) в тот код который ожидался.
Судя по приведенным картинкам посылаемых 4-х битных кодов (на которых сабаки нарисовали всюду идущие подряд комбинации, чем меня смутили и спутали окончательно), 4-х битная часть кода не может состоять с одних 0000 или 1111, тосеть из 32-х битного кода исключаются 16-ть чисел с 1111 и с 0000.
Наверное следует сказать, что сейф-монитор может быть пасивным в сети, тоесть вобще не существовать для ведущего устройства. Он просто слушает запросы мастера и ответы слейвов.
Приведенное выше только догадки (кроме цитат). Кто бы нормальную доку дал, чтоб там это было описано. Есть книги по ASi safe только они платные и дорогие. А мне так для самопросвещения
[img]http://www.radikal.ru][IMG]http://s017.radikal.ru/i423/1205/0d/da921c6c9f4a.jpg[/img]

[san]

[Степа]

Дополнительное поле контрольной суммы разве что может сыграть свою роль в выявлении ошибочного пакета...

Вы сами ответили на свой же вопрос. Это один из механизмов, который используется.

В общем проверил это утверждение практикой: взял один из промышленных протоколов и сравнил, что будет, если ввести дополнительную контрольную сумму. Вероятность просочиться неверному пакету после модернизации "села" на два порядка. НО! В абсолютном выражении число просочившихся пакетов никак не изменилось. Так что дополнительное поле контрольной суммы не всегда приносит именно полезные плоды...

Один из уважаемых специалистов, который написал книгу о проектировании безопасных производств в критическом стиле, тоже написал, что Изернет никуда не годится. Судя из его выражений в книге, он до сих пор думает что там работает CSMA-CD.

Это вообще классика жанра: когда начинается критика Ethernet, то сразу начинают говорить за коллизии...

Степа, Ваш стиль высказывания не терпит других мнений окромя Ваших. Вы можете ошибаться. Для того чтоб что-то критиковать надо в этом что-то разобраться. Я только кусочек зацепил, но не стал бы сразу высказываться что это плохо потому что сложно. Системы часто не запускаются/отказывают не от того, что там микропроцесорные головы в центре, и они сложнее чем релейная автоматика, а потому что плохие контакты.

Да, я могу ошибаться, я этого не отрицаю. Но разбираться-то не в чем, информации кроме рекламных заявлений никаких нет. Тема как раз и создана для получения этой информации. Но некоторые почему-то уверены, рекламные заявления и есть информация. Так это не так.

Итак, значит, 4 принципа:
1. Признак жизни. Последовательное пронумеровывание сообщений.
2. Сторожевой таймер. Ожидание по времени с подтверждением.
3. F-адрес. Позывные имена между отправителем и получателем.
4. CRC. Проверка целостности данных.

1. Признак жизни присутствует в пакетах IP-протокола. Но там он применяется не для безопасности...
Ну выявили потерю пакета, как это отразится на безопасности? Да никак: пакет потерян, что там за информация - никто не знает до её повторения. Да и на самом нижнем уровне выявить потерю можно не вводя дополнительное поле. Протоколы-то построены по принципу "запрос-ответ": запрос ушел, ответа нет - потеря налицо. А для выявления ошибок это поле довольно слабо подходит: CRC гораздо лучше отловит ошибки.
2. Тайм-аут. Присутствует, по моему, во всех известных протоколах: если за некоторое время ответ не пришел, то его не будет вовсе.
3. Адреса есть во всех известных протоколах. Без адресов обходятся только протоколы связи "точка-точка", скажем манипулятор типа "мышь" обменивается с компьютером по безадресному протоколу.
4. Из известных мне только в DCON /это протокол связи с модулями серий ADAM-4000, ICP-CON i-7000/ можно включать или выключать наличие CRC в пакете. В остальных они просто есть.
Вывод: практически все открытые протоколы есть безопасные протоколы /DCON с некоторыми оговорками - CRC должен быть включен при конфигурации сети/.

[Василий Иванович]

Стёпа, если Вы невнимательно (если вообще) читаете написанное другими, то Вам никто не в силах будет помочь.