Цель – показать, какие есть возможности по интеграции сетей и систем. Но речь идет именно про возможности, а не про потребности.
Вопрос не в том, “почему (и когда) нужно применять CAN, а нельзя применять Modbus”. Вопрос в том, что делать, когда все уже есть. И как с этим можно работать.
Например, есть одна сеть CANBUS, а вторая PROBUS. И между их обитателями нужно настроить взаимодействие. Или получать данные из обеих сетей, например, для совокупного анализа.
Мы осознанно абстрагируемся от задач технолога, мы решаем технические вопросы. Например, тот самый вопрос интеграции промышленных сетей. Можно поставить шлюз из промышленной сети в Ethernet. Можно подсоединения с одного компьютера к разным сетям, используя платы, а можно через USB. А еще есть вопросы, которые в статье анонсированы, например, диагностика и тестирование сетей PROFIBUS и CANBUS. Но это уже не интеграция, а эксплуатация.
Резюмируя, у нас была цель — с новой стороны посмотреть на старые проблемы по интеграции и показать, как эти проблемы решаются средствами Softing.
>>Rs232 в качестве сети верхнего уровня — вообще цирк
Абсолютно верно, это приведено как то, что было, с чем наши герои столкнулись. И потом (в первом эпизоде) они вставили пару карт, и все заиграло.
Про деньги – вы правы. Но с другой стороны вам как владельцу корабликов и корабля наверняка известно, что иногда лучше купить решение, чем влезть самому и потом заниматься постоянной докруткой.
Ага, чувствуется хватка специалиста! Спасибо за комментарий.
1. Profibus и т.д. — это, конечно, стандарты. Но также так называют группу протоколов, которые по этим сетям работают. Это чем-то похоже на то, что вы говорили по SCADA и АСУТП, что в определенных кругах считается синонимами (хотя такими не являются, об этом ниже)
2. Согласен, я сам в молодости работал с сетями на основе RS485, а подключение к сети было по RS232.
4. >> проще «убить чем прокормить»
Иногда такое бывает, что и не убьешь.
5. Если вас интересуют технические решения для реальных объектов – то там, разумеется, есть резервирование и прочие штуки. И таких многообразий решений нет. Но все это скучно… Давайте не будем слишком серьезными.
6. Не соглашусь. АСУТП = SCADA + контроллеры + сети. Мы тоже иногда говорим Ленин, подразумеваем партия, но есть нюанс.
>>Различие между SCADA и DSC предмет споров и дискуссий взрослых дядек последние лет 10, лучше не ввязываться )
Знаете, у нас есть центры компетенции по WinCC и PCS7, вы, судя по всему в курсе того, что это такое. Так что мы готовы поспорить с большими дядьками (улыбка).
>>Теперь по делу:
О, вы заговорили нашим языком и это здорово! Пример про естественные ограничения я бы всавил в статью, если бы сам придумал.
По смыслу — да в реальной жизни впереди идут требования и ТЗ, а потом архитектура. Но здесь чуть-чуть по-другому. Здесь уже все эти сети и устройства есть. И мы рассматриваем, как с этим жить, как интегрировать разные сети и т.п.
Еще раз спасибо за вдумчивый комментарий!
Изначально статья задумывалась как реклама для одного журнала. Но потом то, что получилось, вышло за рамки исходной идеи. И по объему и по смыслу. Поэтому я счел возможным разместить ее здесь.
Абзацы добавил, за критику спасибо.
По поводу цели и задач.
Есть область под названием промышленная автоматизация.
Там есть свои сети, свои компьютеры, свои проблемы и решения.
Одна из проблем — это интеграция. Именно ей посвящена статья.
Но писать про реальный завод, который выпускает реальную продукцию нам не интересно.
Поэтому мы и написали про космический корабль.
Проблема известная, у нас тоже есть.
Мы пытались разобраться в причинах и поняли, что беды две: личные качества и коммуникации.
С первым ничего кардинального не сделаешь (не пороть же!). Можно только лучше думать, когда берешь людей на работу. И общаться с теми, кто есть, не замалчивать проблемы.
А про коммуникации подумать стоит. Мы, например, у себя просто посадили тестировщиков вместе с программистами. Стало лучше.
В книге “Управление жизненным циклом …” делается анализ поведения организации и людей на разных этапах жизненного цикла. Это первый шаг. Далее рассматриваются причины старения организаций и сами процессы старения.
Среди этапов есть некая оптимальная точка (вернее оптимальный участок кривой), куда с точки зрения Адизеса нужно стремиться попасть молодым растущим фирмам и стремиться вернуться старым.
Эти подготовительные шаги дают методику анализа.
А потом в книге дается ответ на вопрос “Как?”. Как вывести или вернуть организацию в ту самую оптимальную точку. Именно поэтому используется термин “менеджмент изменений”.
Во второй книге (“Стили менеджмента …”) описываются стили руководителей. Она дополняет первую. В первой описание ролей и стилей занимает 30 страниц, что достаточно для первоначального знакомства, но не снимает всех вопросов. А во второй уже дается полный детальный анализ каждого стиля.
Google знает все. Книжки есть в электронном виде, их можно скачать.
Но мне подобные книги больше нравится читать в бумажном виде. А денег на них не жалко.
Вопрос не в том, “почему (и когда) нужно применять CAN, а нельзя применять Modbus”. Вопрос в том, что делать, когда все уже есть. И как с этим можно работать.
Например, есть одна сеть CANBUS, а вторая PROBUS. И между их обитателями нужно настроить взаимодействие. Или получать данные из обеих сетей, например, для совокупного анализа.
Мы осознанно абстрагируемся от задач технолога, мы решаем технические вопросы. Например, тот самый вопрос интеграции промышленных сетей. Можно поставить шлюз из промышленной сети в Ethernet. Можно подсоединения с одного компьютера к разным сетям, используя платы, а можно через USB. А еще есть вопросы, которые в статье анонсированы, например, диагностика и тестирование сетей PROFIBUS и CANBUS. Но это уже не интеграция, а эксплуатация.
Резюмируя, у нас была цель — с новой стороны посмотреть на старые проблемы по интеграции и показать, как эти проблемы решаются средствами Softing.
Абсолютно верно, это приведено как то, что было, с чем наши герои столкнулись. И потом (в первом эпизоде) они вставили пару карт, и все заиграло.
Про деньги – вы правы. Но с другой стороны вам как владельцу корабликов и корабля наверняка известно, что иногда лучше купить решение, чем влезть самому и потом заниматься постоянной докруткой.
1. Profibus и т.д. — это, конечно, стандарты. Но также так называют группу протоколов, которые по этим сетям работают. Это чем-то похоже на то, что вы говорили по SCADA и АСУТП, что в определенных кругах считается синонимами (хотя такими не являются, об этом ниже)
2. Согласен, я сам в молодости работал с сетями на основе RS485, а подключение к сети было по RS232.
4. >> проще «убить чем прокормить»
Иногда такое бывает, что и не убьешь.
5. Если вас интересуют технические решения для реальных объектов – то там, разумеется, есть резервирование и прочие штуки. И таких многообразий решений нет. Но все это скучно… Давайте не будем слишком серьезными.
6. Не соглашусь. АСУТП = SCADA + контроллеры + сети. Мы тоже иногда говорим Ленин, подразумеваем партия, но есть нюанс.
>>Различие между SCADA и DSC предмет споров и дискуссий взрослых дядек последние лет 10, лучше не ввязываться )
Знаете, у нас есть центры компетенции по WinCC и PCS7, вы, судя по всему в курсе того, что это такое. Так что мы готовы поспорить с большими дядьками (улыбка).
>>Теперь по делу:
О, вы заговорили нашим языком и это здорово! Пример про естественные ограничения я бы всавил в статью, если бы сам придумал.
По смыслу — да в реальной жизни впереди идут требования и ТЗ, а потом архитектура. Но здесь чуть-чуть по-другому. Здесь уже все эти сети и устройства есть. И мы рассматриваем, как с этим жить, как интегрировать разные сети и т.п.
Еще раз спасибо за вдумчивый комментарий!
По поводу цели и задач.
Есть область под названием промышленная автоматизация.
Там есть свои сети, свои компьютеры, свои проблемы и решения.
Одна из проблем — это интеграция. Именно ей посвящена статья.
Но писать про реальный завод, который выпускает реальную продукцию нам не интересно.
Поэтому мы и написали про космический корабль.
Мы пытались разобраться в причинах и поняли, что беды две: личные качества и коммуникации.
С первым ничего кардинального не сделаешь (не пороть же!). Можно только лучше думать, когда берешь людей на работу. И общаться с теми, кто есть, не замалчивать проблемы.
А про коммуникации подумать стоит. Мы, например, у себя просто посадили тестировщиков вместе с программистами. Стало лучше.
Среди этапов есть некая оптимальная точка (вернее оптимальный участок кривой), куда с точки зрения Адизеса нужно стремиться попасть молодым растущим фирмам и стремиться вернуться старым.
Эти подготовительные шаги дают методику анализа.
А потом в книге дается ответ на вопрос “Как?”. Как вывести или вернуть организацию в ту самую оптимальную точку. Именно поэтому используется термин “менеджмент изменений”.
Во второй книге (“Стили менеджмента …”) описываются стили руководителей. Она дополняет первую. В первой описание ролей и стилей занимает 30 страниц, что достаточно для первоначального знакомства, но не снимает всех вопросов. А во второй уже дается полный детальный анализ каждого стиля.
depositfiles.com/ru/files/2frq1qkuh
Клева, спасибо, я ее посмотрю
Но мне подобные книги больше нравится читать в бумажном виде. А денег на них не жалко.