Комментарии 108
Когда мне говорят про хорошие современные интерфейсы — я хватаюсь за пистолет (почти (ц)).
хотел бы сказать, что я не являюсь дизайнером и не получал такого образования, в моей команде тоже нет дизайнероввозможно, с этого и надо было начинать, чтобы такой серьезный текст можно было сразу воспринимать немного более критически.
мы хорошие инженеры, программисты и проектировщикиЕсли Вы используете SCADA системы, основная цель которых избавиться от программистов, то какую роль в Вашей команде выполняют программисты, тем более хорошие? Или это просто эникейщики? Предвосхищая взрыв негодования и снисходительного объяснения «для человека не в теме» — 20 лет назад я, уже будучи программистом с более чем 10-летним опытом, имел несчастье вляпаться в АСУТП и познать кого там принято называть «программистом». Те несколько лет, что я варился в этой области, я считаю самым бездарно потраченным отрезком своей жизни в профессиональном плане.
Можно развернуть проблему?
Scada не призвана избавиться от программистов, это инструмент для программиста. Внутри нижнего и верхнего уровня много работы для программиста. Бывают сложные алгоритмы со многими сценариями, которые все нужно предусмотреть, не нужно еще и забывать про ответственность. Если скрипт будет написано не правильно и в ТЦ погаснет вдруг весь свет вечером, то может хорошо так прилететь. В АСУТП тем более, можно по ошибке остановить производственный процесс, остановка которого может стоить миллионы в час. Поэтому, да, у нас программисты и мы очень трепетно относимся к работе.
Ни какой это не инструмент программиста, а именно попытка избавиться от программистов и заменить квалифицированный труд на менее квалифицированный. Если бы это изначально было ориентировано на программистов, то это была бы не закрытая SCADA система, а некий фреймворк и обязательно с полностью открытым исходным кодом.
По поводу ответственности я с Вами полностью согласен, но именно связывание программиста по рукам и ногам SCADA системой лишает разработчика принять на себя всю эту ответственность. О какой вообще ответственности может идти речь, когда какой-нибудь условный InTouch выбрасывает окно с сообщением «Error XXX in file YYY.cpp line ZZZ», а что именно содержится в строке ZZZ файла YYY.cpp известно только разработчикам SCADA? И дальше вместо нормальной работы начинается поиск обхода чужого косяка на ощупь методом тыка, попутно переписываясь с авторами сего поделия в надежде, что к следующей версией они это может быть исправят (попутно внеся новые ошибки).
По поводу ответственности я с Вами полностью согласен, но именно связывание программиста по рукам и ногам SCADA системой лишает разработчика принять на себя всю эту ответственность. О какой вообще ответственности может идти речь, когда какой-нибудь условный InTouch выбрасывает окно с сообщением «Error XXX in file YYY.cpp line ZZZ», а что именно содержится в строке ZZZ файла YYY.cpp известно только разработчикам SCADA? И дальше вместо нормальной работы начинается поиск обхода чужого косяка на ощупь методом тыка, попутно переписываясь с авторами сего поделия в надежде, что к следующей версией они это может быть исправят (попутно внеся новые ошибки).
… то это была бы не закрытая SCADA система…
OpenSCADA, RapidSCADA, CoreSCADA…
Мало? Напишите свой «фреймвёрк», все протоколы строго стандартизованы, интерфейсы детально документированы.
Не относитесь пренебрежительно к специалистам в тех областях, смысл которых лично Вам непонятен. Поверьте — они имеют полное право презирать Вас точно так же.
В большинстве случаев выбор SCADA ограничен заказчиком — либо они с чем то уже работали и не хотят ничего незнакомого, либо «корпоративный стандарт» и т.д.
все протоколы строго стандартизованытолько далеко не все открыты.
Не относитесь пренебрежительно к специалистам в тех областях, смысл которых лично Вам непонятен. Поверьте — они имеют полное право презирать Вас точно так же.это отношение не к специалистам, а к сложившейся в отрасли практике. И Вы правы, мне никогда не будет понятно стремление называть вещи не своими именами.
Мало? Напишите свой «фреймвёрк»Во многих конторах с этого все и начиналось. Но потом пришли «эффективные менеджеры», и с тем же неистовством, с которым они сейчас вопят о «импортозамещении», тогда, в двухтысячных, они вопили «хочу SCADA, причем непременно от фирмы Siemens, Wonderware и т.д. (смотря кто им проплатил), потому что это — корпоративный стандарт». Именно тогда из отрасли настоящие программисты и побежали косяками, а на их место пришли эникейщики. Потом, правда, оказалось, что не все так красиво, как показано в презентациях, где благодаря магическому слову SCADA все задачи можно решить, посадив «девочку», научившуюся мышкой перетаскивать квадратики.
Вообще-то это инструмент из-за которого программисты возникли как класс. Почитайте историю. Программирование вообще возникло как весьма примитивная программа управления ткацкими станками, где полёта фантазии вообще нет. Да есть легаси, потому что именно промышленность оказалась первой сферой готовой тратить средства на программистов. Да эта сфера не особо терпит всего нового, модного, молодёжного. Потому как надёжность — гораздо, гораздо дороже. Если думаете, что это проблема АСУТП и SCADA, то глубоко ошибаетесь. Этот отпечаток несут все Safety Critical сферы, где можно кого-то зашибить ненароком или подвисание программы выльется в милионы долларов. Я такое встречал как в АСУТП, так и в написании ПО для Medical Devices, авионике, морской навигации, даже в мега-портале юридической направленности. А всё потому что "красота" там спонсируется в последний момент. Средства скорее потратят на 5 лишних туров тестирования, чем на перерисовку. Потому что за "не красивый" интерфейс — максимум напишут просьбу улучшить. А за прокол в функционале, либо посадят, либо потребуют много денег. Именно поэтому в Enterprise и той же SCADA крайне мало OpenSource. Заказчик не хочет OpenSource по одной причине, если что-то случится по вине 3rd party библиотеки за которую заплатили деньги, отвечать будет разработчик той библиотеки, а в случае OpenSource — тот кто разрешил ее использовать в своём продукте. Никто не хочет неcти ответственность за то что сам не делал. Именно по этой причине данные отрасли так "нетерпимы" к OpenSource.
Если вам такое не по душе, лучше смотреть на IoT, web/mobile/application, game dev. Не даром эти отрасли являются локомотивами новых технологий.
Вообще-то это инструмент из-за которого программисты возникли как класс.здесь Вы путаете инструмент и область, в которой он используется. На заре автоматизации не было никаких SCADA систем в современном понимании. И когда появилась аббревиатура SCADA, она первоначально обозначала не инструмент, а саму систему (Supervisory Control And Data Acquisition — диспетчерское управление и сбор данных). Специализированные инструменты появились много позже и переняли давно уже существующие название.
Этот отпечаток несут все Safety Critical сферы, где можно кого-то зашибить ненароком или подвисание программы выльется в милионы долларов. Я такое встречал как в АСУТП, так и в написании ПО для Medical Devices, авионике, морской навигации, даже в мега-портале юридической направленности.Я не знаю, какие инструменты используются для юридических порталов, но в действительно ответственных применениях доминирует MISRA C, и только АСУТП пошло по пути создания своих недоязыков программирования.
Если вам такое не по душе, лучше смотреть на IoTя в общем-то к чему-то подобному и пришел, только еще до того, как аббревиатура IoT стала широко использоваться, во всяком случае у нас.
АСУТП пошло путем создания своих языков, потому что все остальные языки программирования возникли позже. Тут смысл был дать возможность программировать технологам и инженерам, потому что слова программист тогда еще даже толком небыло. А когда появилось, таких людей было крайне мало, чтобы обслужить всю промышленность. Как должен был данный инструмент быть создан для людей которых еще не существовало?
SCADA тут конечно несколько сбоку, но отрасль накладывает свой отпечаток. Изначально для отображения использовались картонно-деревянные стенды с лампочками и цифровыми блоками. Вероятно, они были даже более читаемые, менее вредные для зрения, и даже возможно красивее интерфейсов особенно на первых дисплеях. Когда производство дисплеев стало дешевле, чем работа напильником по дереву, стали ставить дисплеи и изобрели SCADA системы для отрисовки всего того с чем прекрасно справлялись стенды из картона или дерева с лампочками. Собственно инструмент создавался для людей которые уже работали на производстве и создан намеренно просто, чтобы не требовалось дорогостоящее переобучение персонала. Вероятно сейчас стоит пересмотреть данную парадигму, потому как программисты уже не такой дефицит и скорее инженеров способных разобраться в релейных схемах или хорошо оперирующих элементами Буллевой логики найти будет посложнее.
Прекрасное замечание!
Как дополнительную иллюстрацию в аспекте КритическиВажных систем можно также привести пример с Бураном. При разработке бортового ПО был весьма успешно применён комплекс, в котором «недопрограммисты» (в терминах Сергея) «двигают мышкой квадратики по экрану». Можно сколь угодно смеяться над фанатичной увлечённостью Паронлданова и «идиотскими» названиями сущностей (например, «икона» вместо «программный модуль») — но в системе Дракон программированием пилотажного комплекса занимались специалисты в своих профессиональных областях: АСУ-шники, баллистики, аэродинамики, гидравлики. И все вот эти «недопрограммисты» «двигая иконы мышью» в кратчайший срок и почти без косяков создали сложнейший программный комплекс. Лично я не знаю ни одного «тру-программера», который при этом прекрасно разбирался бы в АСУ или гидравлике.
Как дополнительную иллюстрацию в аспекте КритическиВажных систем можно также привести пример с Бураном. При разработке бортового ПО был весьма успешно применён комплекс, в котором «недопрограммисты» (в терминах Сергея) «двигают мышкой квадратики по экрану». Можно сколь угодно смеяться над фанатичной увлечённостью Паронлданова и «идиотскими» названиями сущностей (например, «икона» вместо «программный модуль») — но в системе Дракон программированием пилотажного комплекса занимались специалисты в своих профессиональных областях: АСУ-шники, баллистики, аэродинамики, гидравлики. И все вот эти «недопрограммисты» «двигая иконы мышью» в кратчайший срок и почти без косяков создали сложнейший программный комплекс. Лично я не знаю ни одного «тру-программера», который при этом прекрасно разбирался бы в АСУ или гидравлике.
Продолжая дискуссию (мне нравится конфуцианская её сдержанность): лично я знаю лишь нескольких людей, которых могу с чистой совестью назвать «тру-программерами». Большинство моих знакомых «программистов» совершенно не владеют ни математическими, ни алгебраическим основами — и, хуже того!-- они в большинстве своём ужасно некультурны. Элементарно не могут найти общий язык с заказчиком (владельцем бизнеса).
Именно это большая проблема.
Касательно Сергея: в своих комментариях (он не единичен, Сергей оставил около десяти) уважаемый оппонент раз ра разом подтверждал лишь единый тезис: опытный программист, оказавшийся в не то время не на том месте и (извините, Сергей!) не удосужившийся получить качественное «высшее образование».
Именно это большая проблема.
Касательно Сергея: в своих комментариях (он не единичен, Сергей оставил около десяти) уважаемый оппонент раз ра разом подтверждал лишь единый тезис: опытный программист, оказавшийся в не то время не на том месте и (извините, Сергей!) не удосужившийся получить качественное «высшее образование».
Мне кажется, это распространённое заблуждение, что программист — это профессия, требующая высшего образования. В странах, до которых девальвация высшего образования пока не дошла в полной мере (Германия, Австрия) программистов обучают в техникумах — это трёхлетнее среднее специальное образование.
Если проводить аналогии с более старыми профессиями, есть рабочая профессия «сварщик», которой обучаются три года в училище/техникуме/колледже. Они имеют представление о физике/математике, отлично сваривают детали, особенно если известно какую к какой нужно приварить. Есть инженеры, которых обучают в ВУЗах 5-6 лет. Они разрабатывают технологические процессы, поэтому им нужно глубокое понимание физики, владение мат. аппаратом, но сваривать средний инженер всё равно будет хуже среднего сварщика.
Все (надеюсь) любят сварщиков за их прямоту, остроумие и владение матом, и никто не будет упрекать хорошего сварщика в том, что он не удосужился получить высшее образование.
Так и к программистам, как мне кажется, не нужно предъявлять повышенные требования только лишь на том основании, что работают они не в спецовке.
Если проводить аналогии с более старыми профессиями, есть рабочая профессия «сварщик», которой обучаются три года в училище/техникуме/колледже. Они имеют представление о физике/математике, отлично сваривают детали, особенно если известно какую к какой нужно приварить. Есть инженеры, которых обучают в ВУЗах 5-6 лет. Они разрабатывают технологические процессы, поэтому им нужно глубокое понимание физики, владение мат. аппаратом, но сваривать средний инженер всё равно будет хуже среднего сварщика.
Все (надеюсь) любят сварщиков за их прямоту, остроумие и владение матом, и никто не будет упрекать хорошего сварщика в том, что он не удосужился получить высшее образование.
Так и к программистам, как мне кажется, не нужно предъявлять повышенные требования только лишь на том основании, что работают они не в спецовке.
Сильно отхожу от темы, но если уж речь пошла о сварщиках, то я знал одного аж с двумя высшими образованиями.
Да, в плане именно программирования автоматизация довольно скучна, но на то свои причины — уже упомянутая выше ответственность и часто невозможность отладки сырой программы непосредственно на железе (повредить можно). Отсюда и простота языков — поведение программы должно хорошо представляться и проигрываться в голове.
Сразу после выпуска, в начале нулевых, довелось поработать пару лет в автоматизации зданий, поначалу «программирование как в PowerPoint» после С и ассемблеров казалось игрушечным, задачи решались с наскока, а потом в результате моей мелкой ошибки (задал не ту полярность входу) морозом порвало теплообменник (и это я ещё в «несерьёзном» ответвлении работал. У «взрослых» знакомых на «технологии» бывали и помасштабней вещи — гидроудар в магистральном трубопроводе, случайный пуск пенообразователя, в считанные секунды выдающего целое озеро итд). Весьма консервативная область в общем — не усложняй, не абстрагируй, проверяй, перепроверяй.
Так в том и проблема, что создаются примитивные средства разработки в расчете, что ими должны пользоваться не программисты, а специалисты в прикладной области (технологи и т.д.). Но последние умудряются и в таких игрушечных средствах косячить. И тогда раздается вопль «тут нужен программист», но нормальный программист тоже не может эффективно работать из-за примитивности инструмента.
… поведение программы должно хорошо представляться и проигрываться в голове
… не усложняй, не абстрагируй, проверяй, перепроверяйЕсли решаемая задача достаточно сложная, то только хорошее разложение по уровням абстракции может дать понятное, а значит надежно работающее решение. Если инструмент разработки этого не позволяет (или позволяет, но превращает разработку в борьбу с инструментом), то это никак не способствует правильному решению поставленной задачи.
Вот и получается, что ты хочешь сделать красивый, удобный, понятный и простой интерфейс, а тк редактор делается не для программиста, а для людей, которым соединить 3 алгоблока = программирование — не выходит из-за ограничений самого редактора. Иногда даже суровая реальность упирается в казалось бы очевидные вещи, например, некоторые примеры сделаны на ПО, в котором использовать шаблоны было невозможно до недавнего времени, как следствие — при массовом копировании каждого тега в каждом окне где-то всплывают незаметные глазу, но заметные при сравнении смещения и прочие шероховатости.
Но всё же следует очень четко разделять АСУ ТП и BMS, также как и «орган принимающий решение» (будь то ПЛК/сервер/релейная схема) и индикацию = информирование о работе системы, а то мне очень не хочется, чтобы у меня была очень красивая машина, которая может взять и не поехать неизвестно почему.
Но всё же следует очень четко разделять АСУ ТП и BMS, также как и «орган принимающий решение» (будь то ПЛК/сервер/релейная схема) и индикацию = информирование о работе системы, а то мне очень не хочется, чтобы у меня была очень красивая машина, которая может взять и не поехать неизвестно почему.
Непременно нужно именно написание кода в UI части? Предполагаются какие-то динамические действия, которые нужно описывать именно как алгоритмы, причём настолько уникальные от объекта к объекту, что их не заложить готовыми в библиотеку самой SCADA?
Так то и в обсуждаемой статье ни слова о программировании, она больше о дизайне, и где-то там основная проблема и кроется — дизайн UI возлагают на тех же людей, кто программировал PLC ("они ж лучше знают что там внутри"), а им после месяцев глядения в технологическую схему ничего другого уже не видится — получаем "чёрно-зелёную консоль всевластия".
Насчёт разделения управления и индикации — обеими руками за. Периодически общаемся с другом детства, ушедшим в "умные дома" — постоянно мат и жалобы на нестабильность работы новомодных "хабов", по сути совмещающих в себе PLC и web UI (да ещё и в виде какой-нибудь Raspberry внутри DIN-коробочки) — ребята, извините, но у Honeywell и для "гражданских" зданий PLC выглядели как нечто на RTOS, с интерфейсными цепями на керамике, и работало оно так, что на очередном техобслуживании разблокируешь панель и видишь то самое подменю, в котором оставил систему квартал назад. А на отдельном SCADA PC скучающие операторы тем временем втихаря от начальства в Doom играть могли.
В мелких конторах таким «программистом» считается инженер-электронщик, который умеет программировать, он же там и дизайнер, и конструктор, и даже иногда монтажник. Времени на красивый дизайн не остаётся. Для маленьких проектов где-нибудь на заводе такого человека хватает, особенно если учесть, что он работает за еду зарплату инженера-электронщика.
мы знаем, как должны работать системы и как их нужно эксплуатировать, опираясь на это, хотим сделать максимально удобный для человека пользовательский интерфейс
Очень хочется верить в это (без сарказма). Как по мне, и старые, и новые интерфейсы выглядят вполне неплохо с точки зрения UI, а вот с UX у меня опыта работы тут нет, так что оценить и сравнить не могу.
Ещё хотелось бы увидеть больше "как было", ибо сравнить те же окна настройки не получается без этого.
А чем SCADA-системы отличаются от открытых систем домашней автоматизации? Например, Home Assistant.
Добавлю, что графические интерфейсы SCADA могут и должны быть разными. Для АСУ в крупных зданиях (не «домашняя автоматизация») похожие «устаревшие» картинки не являются самым большим грехом. Диспетчер в здании не так часто и не продолжительно смотрит на дисплеи. Его задача быстро найти проблемную область и быстро принять меры. Ваш дизайн, подход к компоновке экранов мне понравился. Я видел несколько десятков подобных систем в крупнейших зданиях Москвы от различных интеграторов: российских и зарубежных. Помимо графики, у вас хорошо скомпонованы элементы управления и контроля, без перегрузки, все самое важное: четко и понятно. В 200-е годы в Москве это редко встречалось. Также важно, какие готовые элементы SCADA предоставляет сам производитель, чтобы интегратору не требовалось выдумывать велосипеды. У больших производителей типа Siemens, Honewewell, JCI дисплеи SCADA собираются, как правило, из готовых графических блоков, места для фантазии там остается мало.
И таки нашел, что можно улучшить: положение клапанов, температуру подачи и(или) обратки теплоносителя в обвязке калориферов вентустановок лучше показывать сразу на мнемосхеме с вентустановкой. Ясно, что общий дизайн несколько страдает, но эксплуатация скажет только спасибо. Кстати, на «устаревших» примерах это есть.
И таки нашел, что можно улучшить: положение клапанов, температуру подачи и(или) обратки теплоносителя в обвязке калориферов вентустановок лучше показывать сразу на мнемосхеме с вентустановкой. Ясно, что общий дизайн несколько страдает, но эксплуатация скажет только спасибо. Кстати, на «устаревших» примерах это есть.
Спасибо за отзыв.
у вас хорошо скомпонованы элементы управления и контроля, без перегрузки, все самое важное: четко и понятно.стараемся следовать именно этому.
у вас хорошо скомпонованы элементы управления и контроля, без перегрузки, все самое важное: четко и понятно.там где ТЦ, там разместили под калорифером, а вот на последнем примере убрал в меню. С замечанием согласен.
Я не настоящий сварщик и UX/UI не занимаюсь, но курсы проходил.
Что бы из этого я применил
1. Контраст — в темной теме мелкие буквы на темном фоне трудно читать. Вообще по устройству глаза палочки отвечают за различие светлого и темного, а колбочки за цвета. Общая структура страницы считывается по принципу светлый-темный, а подробности это цвет.
Один из тестов — попробуйте посмотреть страницу в оттенках серого. Все ли там будет читаемо?
2. Про использование множества цветов. Хитрый момент в том, что если мы возьмем модель HSL и возьмем разные цвета по H, то это будут действительно разные цвета и выглядеть будет пёстро. Но если мы рамках одного H меняем S и L, то это будут вариации одного цвета.
От себя рекомендую посмотреть блог Эрика Кеннеди на предмет UX/UI (Erik Kennedy).
Что бы из этого я применил
1. Контраст — в темной теме мелкие буквы на темном фоне трудно читать. Вообще по устройству глаза палочки отвечают за различие светлого и темного, а колбочки за цвета. Общая структура страницы считывается по принципу светлый-темный, а подробности это цвет.
Один из тестов — попробуйте посмотреть страницу в оттенках серого. Все ли там будет читаемо?
2. Про использование множества цветов. Хитрый момент в том, что если мы возьмем модель HSL и возьмем разные цвета по H, то это будут действительно разные цвета и выглядеть будет пёстро. Но если мы рамках одного H меняем S и L, то это будут вариации одного цвета.
От себя рекомендую посмотреть блог Эрика Кеннеди на предмет UX/UI (Erik Kennedy).
Картинки из примеров в статье — самоделки и/или без опыта. Пытаться по этому экстраполировать на всю область — глупо.
Мне чаще такие встречаются. Тем более по запросу «скада» в яндекс картинках, будут именно такие схемы
«по запросу в яндекс» это очень плохой пример поиска образцов. Лучше брать из «историй успеха» топовых вендоров в данной области, например Honeywell Home, Andover Controls, Siemens SBT — всех на память не вспомню…
по запросу «скада» в яндекс картинках
я 10 лет «рисовал картинки» (Северный поток, Южный, нефтянка и даже атомка) и ни одной картинки нет в интернете, даже на сайте конторы… полагаю так же у большинства коллег… поэтому выборка ни о чём…
А какая причина была уйти от 3D? Сложно перерисовывать?
Считаю, что объёмные варианты — самые естественные, а в этих иконках ещё разобраться надо что они имитируют.
От части прорисовки тоже касается. С вентиляцией и тепловым пунктом понятно, там можно отрисовать набор качественных картинок. Но когда дело касается других процессов, то тут ступор. Как отрисовать в 3Д флотатор или обезвоживатель? Холодильный центр, тоже уже проблемно.
Но мне в целом 3Д не кажется оптимальным вариантом. Картинки места много занимают а полезной информации не несут. Но это мое мнение на основе моего опыта, я могу ошибаться.
Но мне в целом 3Д не кажется оптимальным вариантом. Картинки места много занимают а полезной информации не несут. Но это мое мнение на основе моего опыта, я могу ошибаться.
Операторы вполне привыкли работать с технологическими схемами и им никакое 3D вообще не нужно, им важна информативность. 3D в основном используется для произведения хорошего впечатления при демонстрации «достижений» высокопоставленному руководству.
Тут как обычно два конца.
Если оператор — человек с улицы, ему надо чтобы задвижка на экране выглядела так же как и в живую, а труба была в виде объёмной трубы, иначе он не поймёт что там за линии и что за
треугольники бабочкой. Обучать человека с улицы чтению схем, ради того чтобы он мог включить/выключить вентилятор?
Однако если это серьёзное производство, велика вероятность что там есть технически грамотные специалисты и схемы коммуникаций, по госту, они в работе используют чертежи и привыкли читать чертежи, а когда они видят эту 3D красоту, возникают сложности с пониманием, что нафантазировал себе художник изображая осушитель по картинкам в интернете.
Если оператор — человек с улицы, ему надо чтобы задвижка на экране выглядела так же как и в живую, а труба была в виде объёмной трубы, иначе он не поймёт что там за линии и что за
треугольники бабочкой. Обучать человека с улицы чтению схем, ради того чтобы он мог включить/выключить вентилятор?
Однако если это серьёзное производство, велика вероятность что там есть технически грамотные специалисты и схемы коммуникаций, по госту, они в работе используют чертежи и привыкли читать чертежи, а когда они видят эту 3D красоту, возникают сложности с пониманием, что нафантазировал себе художник изображая осушитель по картинкам в интернете.
Брать на работу оператора без знания технологии процесса, а значит и знания схем — ну такое себе.
Брать на работу человека без знаний — нестареющая классика, любимое развлечение руководителей всех уровней в погоне за экономией. Поэтому в некоторых интерфейсах приходится рисовать картинки для идиотов, с краном в виде крана и вентилятора с анимированными вращающимися лопастями.
Я не работал на мелких предприятиях. У нас было всё по серьезному. Человек сначала несколько месяцев проходил обучение, потом экзамены, потом стажировка под присмотром и опять экзамены, и только потом самостоятельная работа. И никаких идиотских картинок.
Но если погуглить SCADA по картинкам, то там прям всё печально в 100% случаев.
Но если погуглить SCADA по картинкам, то там прям всё печально в 100% случаев.
А какая причина была уйти от 3D?
нахрена оно вообще там нужно ?! это рабочая штука, а не игра… равно как спецодежда не должна быть похожа на тряпки с дефиле
оператору нужно максимальное соответствие экрана с однолинейной или технологической схемой… чтоб в случае чего знать куда бежать и что крутить/рубить…
Общее замечание — в интерфейсах много где используется выделение важной информации цветом, при этом цвета используются одинаковой светлоты (например, на закладке вентиляция явно что-то не так с П2В2, П8В8 и совсем плохо с П1В1 и т.п.). Судя по всему сделано это умышленно (значения L в HSL палитре полностью совпадают) и наверное для красоты. Но в плане юзабилити это довольно опасно.
Во-первых, многие люди не различают некоторые цвета (причём, многие об этом не догадываются) и они просто не считают предупреждение. Во-вторых, чтобы эти сообщения перестали распознаваться, нужно просто достаточно устать от монотонной работы (попробуйте просто прищуриться, например). Наиболее наглядно видно как исчезает информация, если перевести картинку в ЧБ.
Вообще, есть хороший трик, которому обучают иллюстраторов — перед тем как начать работать с цветом, нужно набросать ограниченное количество цветов в оттенках серого так, чтобы картинка всё равно читалась, и при подборе цветов менять только тон и насыщенность.
В остальном смотрится классно и даже примерно понятно что происходит.
Во-первых, многие люди не различают некоторые цвета (причём, многие об этом не догадываются) и они просто не считают предупреждение. Во-вторых, чтобы эти сообщения перестали распознаваться, нужно просто достаточно устать от монотонной работы (попробуйте просто прищуриться, например). Наиболее наглядно видно как исчезает информация, если перевести картинку в ЧБ.
Вообще, есть хороший трик, которому обучают иллюстраторов — перед тем как начать работать с цветом, нужно набросать ограниченное количество цветов в оттенках серого так, чтобы картинка всё равно читалась, и при подборе цветов менять только тон и насыщенность.
В остальном смотрится классно и даже примерно понятно что происходит.
Спасибо. Про оттенки серого полезная информация.
явно что-то не так с П2В2, П8В8 и совсем плохо с П1В1ткните пальцем, не очень понял где
Первая картинка в разделе «Подробнее о создании интерфейса диспетчеризации» и далее.
Явно задача жёлтого и красного цветов сообщить какую-то информацию оператору (жёлтый — требует внимания, красный — критический).
Явно задача жёлтого и красного цветов сообщить какую-то информацию оператору (жёлтый — требует внимания, красный — критический).
Проблема в одинаковой светлоте? Ярче должны быть они?
Зависит от назначения. Если это просто для общей информации, можно оставить маркировку цветом, но разной яркости (значение L в HSL коде). Вообще, лучше исходить из того, что цвета одной яркости — один и тот же цвет в плане передачи информации. Проверить свою палитру можно, например, на coolors.co, там же можно и посмотреть как будут видеть цвета люди с различными отклонениями в восприятии цвета.
Если же требуется реакция оператора, на мой взгляд, лучше только на цвет не полагаться — либо добавить всплывающий символ, либо увеличивать размер надписи, либо сделать по принципу светофора (дополнительная кодировка расположением вверху/внизу). Как и во всём особо ответственном, нужно дублирование функции. Проще говоря — нужно иметь возможность считать важную информацию в ЧБ без особых затруднений.
Если же требуется реакция оператора, на мой взгляд, лучше только на цвет не полагаться — либо добавить всплывающий символ, либо увеличивать размер надписи, либо сделать по принципу светофора (дополнительная кодировка расположением вверху/внизу). Как и во всём особо ответственном, нужно дублирование функции. Проще говоря — нужно иметь возможность считать важную информацию в ЧБ без особых затруднений.
Очень часто добавляют мигание на аварии, но она несколько раздражает, нужно учитывать, что аварию можно и не сбросить сразу, будет на экране мерцать разные значения, не очень приятная штука. Мы в диспетчерской очень много времени провели) и когда заходишь и окидываешь взглядом мониторы, то информация сейчас хорошо воспринимается. По поводу HSL, нужно понимать еще, что моники все разные, цветопередача очень разбегается.
Да, по-моему, одной из причин катастрофы Boeing 727 в Далласе в 1988-м году было то, что пилоты либо систематически отключали раздражающую систему предупреждения о невыпущенных закрылках, либо просто настолько привыкали к её, что игнорировали, т.к. она постоянно срабатывала на рулёжке.
Поэтому я тоже против миганий и любых раздражающих предупреждений. Но я это и не предлагал. Речь только о том, что если хочется передать какую-то информацию цветом, нужно зашифровывать её прежде всего в яркости и уже вторично в тоне (как например в редактора расписания вытяжек или у зелёных стрелок клапанов). К слову, это же и на разных мониторах будет лучше работать. В разных мониторах особо страдает тон, в то время как яркий пиксель ярче тёмного на всех мониторах.
Поэтому я тоже против миганий и любых раздражающих предупреждений. Но я это и не предлагал. Речь только о том, что если хочется передать какую-то информацию цветом, нужно зашифровывать её прежде всего в яркости и уже вторично в тоне (как например в редактора расписания вытяжек или у зелёных стрелок клапанов). К слову, это же и на разных мониторах будет лучше работать. В разных мониторах особо страдает тон, в то время как яркий пиксель ярче тёмного на всех мониторах.
Для меня самое жесткое, что есть в SCADA — это анимации) Нет, конечно взять и показать, что всё красиво работает, это одно, а сидеть на месте оператора и сутки смотреть на всю эту крутящуюся анимацию затея не очень. На самом деле еще не хватает некой, так сказать стандартизации — грубо говоря у меня на последнем из объектов возникла мини проблема — визуализация на веб сервере ПЛК (которую видит оператор удаленно с рабочего компьютера) и визуализация в средстве разработки для панели с разными исходными элементами, соответственно свести воедино получилось только набрав отдельно картинки элементов. Тут мне нравится в целом подходы гугла и эйпл в попытке создать единый дизайн для элементов)
Нет, конечно взять и показать, что всё красиво работает, это одно, а сидеть на месте оператора и сутки смотреть на всю эту крутящуюся анимацию затея не очень.В особых случаях делают 2 варианта экранов — «красивый» с цветами и анимацией, чтобы показать заказчику и «удобный» — для оператора)
ПС: Ниже такую тему уже отметили.
С интересом прочитал статью. Для начала, Вы сильно льстите современным интерфейсам, описывая их как «удобные». Приведенные в начале примеры, в-общем, тоже не образец удобства, так делали в начале 90-х. В Вашем подходе я вижу плюс в том, что его легче сдать некомпетентному человеку, который не заглядывал в проект и не разбирается в функциональных схемах. Операторы же люди подневольные, они и с упрощенными схемами научатся работать. Как они будут называть разработчика, никто не услышит.
Некоторые замечания: десятые доли процентов только мешают, а оборудование не имеет такой точности регулирования. На последней мнемосхеме яркие заголовки не дают быстро увидеть состояния систем, отвлекают. Надеюсь, пусконаладочные параметры вентсистем не постоянно висят на экране, они же не нужны для эксплуатации. Не видно, есть ли графическое отображение аварий прямо возле агрегата и индикация ручного управления для каждого элемента. Чтобы ввести символ градуса (°), нажмите левый Alt, наберите 248 на цифровой клавиатуре, отпустите Alt. «С» — это не "°С"
Когда Segnetics попытался сделать «дизайнерский» интерфейс на своих графических панелях управления, это отвратило меня от них окончательно. По-моему, не стоит придумывать новые обозначения для широко используемых компонентов. Я в реализуемых проектах делаю так, чтобы мнемосхема была похожа на проектную функциональную схему или отражала реальное расположение оборудования. Для большого количества однотипных объектов — списки с выделением цветом, как у Вас.
Некоторые замечания: десятые доли процентов только мешают, а оборудование не имеет такой точности регулирования. На последней мнемосхеме яркие заголовки не дают быстро увидеть состояния систем, отвлекают. Надеюсь, пусконаладочные параметры вентсистем не постоянно висят на экране, они же не нужны для эксплуатации. Не видно, есть ли графическое отображение аварий прямо возле агрегата и индикация ручного управления для каждого элемента. Чтобы ввести символ градуса (°), нажмите левый Alt, наберите 248 на цифровой клавиатуре, отпустите Alt. «С» — это не "°С"
Когда Segnetics попытался сделать «дизайнерский» интерфейс на своих графических панелях управления, это отвратило меня от них окончательно. По-моему, не стоит придумывать новые обозначения для широко используемых компонентов. Я в реализуемых проектах делаю так, чтобы мнемосхема была похожа на проектную функциональную схему или отражала реальное расположение оборудования. Для большого количества однотипных объектов — списки с выделением цветом, как у Вас.
Спасибо за отзыв.
десятые доли процентов только мешаютОтчасти согласен, но в некоторых местах они нужны. Например процент открытия клапана и важные температуры, при изменение уставок так проще смотреть как реагирует привод и как настроен ПИД. Если десятых нет, то очень долго ждать изменений.
Надеюсь, пусконаладочные параметры вентсистем не постоянно висят на экранеО каких именно речь идет?
есть ли графическое отображение аварий прямо возле агрегатанету, пока, но это важный момент, будем реализовывать ее обязательно.
и индикация ручного управленияв этих примерах нету, но на других объектах где это есть, обязательно показываем.
Когда Segnetics попытался сделать «дизайнерский» интерфейсМне лично нравится то, что делает Сегнетикс. И дизайн интерфейсов и дизайн оборудования.
Несколько лет проработал в КИП на пищевом предприятии. Занимался автоматизацией всего чего угодно. Меня изменил момент, когда операторы попросили сделать интерфейс без свистелко-перделок:«так чтобы только цифры, надписи и кнопки».
Оказывается ребята очень страдали от красивых картинок. Они загромождали рабочий стол и в одночасье можно было видеть только часть процесса. После таких замечаний, я делал два интерфейса: первый для начальства — красивый и с картинками, а второй для операторов.
Оказывается ребята очень страдали от красивых картинок. Они загромождали рабочий стол и в одночасье можно было видеть только часть процесса. После таких замечаний, я делал два интерфейса: первый для начальства — красивый и с картинками, а второй для операторов.
Да, это почти везде так. Мы стараемся как раз этому и следовать, убирать максимум красивых и не красивых картинок, но тем не менее, информацию нужно как-то структурировать для удобства и ориентации, поэтому все 3Д, крутилки, мигание и мерцание убираем, оставляем прямоугольники согласно схеме и переменные и подсказки.
«После таких замечаний, я делал два интерфейса: первый для начальства — красивый и с картинками, а второй для операторов.»
Отличная идея! Очень правильная во всех смыслах.
Я так всегда с сайтами и мелкими своими программками делаю. Началось всё ещё в эпоху WAP (кто-то ещё помнит, что это за штука? :-) ); закономерно продолжилось с появлением планшетов/смартфонов (масштабируемые дизайны и всё это вот) и — естественным способом транслировалось в общую идею «один интерфейс чтобы запудрить глаза покупателю; второй — чтобы пользователю было реально удобно».
Отличная идея! Очень правильная во всех смыслах.
Я так всегда с сайтами и мелкими своими программками делаю. Началось всё ещё в эпоху WAP (кто-то ещё помнит, что это за штука? :-) ); закономерно продолжилось с появлением планшетов/смартфонов (масштабируемые дизайны и всё это вот) и — естественным способом транслировалось в общую идею «один интерфейс чтобы запудрить глаза покупателю; второй — чтобы пользователю было реально удобно».
Моя тема. Несколько лет рисовал картинки в Транснефти. У них существует приличный гайд по описанию всего — цвета, расположения, состава, шрифтов, слоёв и т.д. Это дало то, что в любой дочке ТН в любом месте были одинаковые интерфейсы на уровне диспетчерских отделов.
Выше правильно написали, что интерфейсы бывают разными. В один заглядывают только при наличии проблем, а в другой смотрят круглосуточно. Оба должны по-разному реализовываться.
А вообще тема избитая, есть, например, HMI Design Workbook от Siemens, или The High Performance HMI от Rockwell, или можно поучиться вот у этих ребят — hmi-project.com
Выше правильно написали, что интерфейсы бывают разными. В один заглядывают только при наличии проблем, а в другой смотрят круглосуточно. Оба должны по-разному реализовываться.
А вообще тема избитая, есть, например, HMI Design Workbook от Siemens, или The High Performance HMI от Rockwell, или можно поучиться вот у этих ребят — hmi-project.com
По ссылкам нашел очень много полезного, спасибо.
У Транснефти не гайд, а документ ТПР (типовые программные решения, часть 5), страниц эдак на 1000 — чтобы интерфейсы от разных производителей управлялись и ощущались одинаково (алгоритмы так же унифицированы).
Это сделано затем, чтобы в одной операторной — а я лично наблюдал решения от 3х разных Интеграторов в одной операторной, не было разночтений. Представьте вариант, когда оператор «путает педали» в режиме аврала.
В противовес скажу, что технологии у ТН простейшие, а для более сложных процессов можно и утомиться собирать наименьший общий делитель для алгоритмов и интерфейсов. Но опять же, Major PCS vendors это стараются делать
Это сделано затем, чтобы в одной операторной — а я лично наблюдал решения от 3х разных Интеграторов в одной операторной, не было разночтений. Представьте вариант, когда оператор «путает педали» в режиме аврала.
В противовес скажу, что технологии у ТН простейшие, а для более сложных процессов можно и утомиться собирать наименьший общий делитель для алгоритмов и интерфейсов. Но опять же, Major PCS vendors это стараются делать
Я говорю не про операторные на станциях, а про диспетчерские на уровне управлений, там другой гайд — РД-35.240.60-КТН-029-15. А в операторных, конечно, полный трэш, может стоять решение от Элеси на GraphWorx и от них же на их HMI, а рядом противопожарка от Болид. Упомянутый вами документ распространяется только на вновь вводимые системы, старые никто не переделывает, поэтому если не было реконструкций, то этот зоопарк так и стоит. Пройдет еще с десяток лет, пока на уровне НПС (ЛПДС) всё не станет однотипным.
А педали путали не раз как операторы, так и диспетчеры. Останавливали не тот агрегат по запаре, например. Но ТН это же не переработка, а транспорт, там из-за неверных действий оператора ничего страшного не произойдёт, кроме снижения объемов перекачки.
А педали путали не раз как операторы, так и диспетчеры. Останавливали не тот агрегат по запаре, например. Но ТН это же не переработка, а транспорт, там из-за неверных действий оператора ничего страшного не произойдёт, кроме снижения объемов перекачки.
Я ТН не ругаю, скорее наоборот. В противовес статье.
Но даже на транспорте нефтепродуктов можно еще как накосячить
ЗЫ. Элеси вроде ставила свою Инфитити, а Графворкс относится к Дженезис.
Но даже на транспорте нефтепродуктов можно еще как накосячить
ЗЫ. Элеси вроде ставила свою Инфитити, а Графворкс относится к Дженезис.
ЗЫ. Элеси вроде ставила свою Инфитити, а Графворкс относится к Дженезис.
Всё верно, но изначально у них не было своей HMI и они использовали GraphWorx в качестве верхнего уровня. До сих пор все диспетчерские схемы во всей ТН реализованы на GraphWorx. Собственный HMI используется на уровне НПС.
Я с продуктами Элеси работал с 2000 по 2017 годы, когда еще их продукт Infinity не назывался :)
Но даже на транспорте нефтепродуктов можно еще как накосячить
По официальной версии, причиной инцидента стала разгерметизация одного из резервуаров из-за проседания свай фундамента.
Ну, как бы, причем тут действия оператора/диспетчера? Вся автоматика в ТН (да и просто грамотная автоматика) реализуется так, чтобы отсутствие визуальных данных у оператора/диспетчера (сервер скады сломался, например) никаким образом не влияло на техпроцесс. Все защиты реализованы в ПЛК., всё сработает само, если надо. Даже если специально запустить агрегат на закрытую задвижку, то сработает датчик давления и датчик тока на агрегате. Перелить резервуар тоже не получится, всё в датчиках, и т.д. Если только намеренно отключить защиты, но это уже другой вопрос.
каждый производитель системы предоставляет свои наборы готовых библиотек,… чаще всего эти библиотеки не отличаются качеством своего исполнения.
Немного смутил такой явно критический тон, во первых SCADA системы предоставляют элементарные средства для разработки, все остальное зависит от вашего профессионализма. Почему только элементарное, вы же сами и ответили «призванные упростить и ускорить работу программиста».
На просторах интернета полным полно готовых графических наработок под популярные SCADA системы.
Опять же смутило, что дизайнер — это дорого, но как я понял Вы нанимали для данного проекта дизайнера.
Дизайн действительно качественный, проработанный, интуитивно понятный. Но опять же, прикладное программное обеспечение, точнее визуализация, очень привязана к технологии. Насколько вы корректно, понятно, прозрачно отобразите технологию на столько она и будет хороша, не только качественная графика (конечно так же необходима).
Черный фон не использую, т.к. большой контраст между другими цветами (белый, красный желтый), использую серый фон наиболее щадящий для глаз. Немного странно было читать про спящих операторов и черный цвет что бы их не разбудить. Ну разве что у вас все таки диспетчеризация а не управляющая система реального времени.
Ну и я явно не увидел главный посыл статьи- создание модулируемых графических объектов с возможностью дальнейшего применения, как я понял нет, графика на дизайнере на каждый скрин своя. Т.е. для следующего объекта вам нужно нанимать дизайнера и заново все прорисовывать почти с 0. А это деньги и время (=деньги)
Прошу прощения за может излишнюю критичность, т.к. на вкус и цвет все фломастеры разные.
Спасибо за отзыв!)
как я понял Вы нанимали для данного проекта дизайнерананимал дизайнера на первый свой серьезный проект, так как опыта была очень мало. Дальше, все что мы делали, делали уже сами.
Черный фон не используюСтрого черный цвет будет жутко для глаз, у нас он чуть в серый и синий уходит.
Немного странно было читать про спящих операторовСкорее не операторов, а персонал в диспетчерской, на разных объектах, разный состав в диспетчерской, охрана, операторы и тд, некоторые ночуют в диспетчерской.
создание модулируемых графических объектовНу мы практически к этому пришли. Спевра убрали все 3Д, которое сложно унифицировать, а потом сделали прямоугольники с информацией. Логика в том, чтобы структурировать процесс по разным элементам, один элемент это прямоугольник с основной информацией внутри. Прямоугольники немного меняются у нас от объекта к объекту, углы, тени, обводки, но смысл остается. Такая логика позволяет сделать однотипными систему вентиляции, котельную, хладоцентр, очистные, и тд.
Вот следуя такой логике реализовали очистные сооружения
Смотрится интересно, но есть минус — не видно технологии. Оператору придётся держать распечатку рядом с рабочим местом. Но это опять же зависит от заказчика.
А если ткнуть на значение откроется окно параметра с возможностью вывода графика и просмотра уставок?
п.с. Автоматизация очистных сооружений была у меня дипломным проектом :)
А если ткнуть на значение откроется окно параметра с возможностью вывода графика и просмотра уставок?
п.с. Автоматизация очистных сооружений была у меня дипломным проектом :)
Верно замечено. Технологии необходимо как правило несколько больше. Т.е. к очистным, насосным установкам добавить информацию по обслуживаемым частям зданий, технологических подсистемам. Как правильно заметили, чтобы эксплуатация экономила время на работу с документацией. Пришла авария по КНС, видим сразу в какой части технологии возникла проблема, т.е. куда бежим, что проверяем, закрываем и т.п.
В конце концов, сейчас у всех в руках смартфоны с современными ОС и приложениями — люди давно уже привыкли к хорошим качественным интерфейсам, а мы заставляем их возвращаться в прошлое во времена Windows 98.Принципы проектирования UI Win95.
Возвращать нас в те времена кажется уже некому…
Зачастую у людей, заказывающих АСУ ТП уже есть опыт использования таких систем. И это опыт из 90-х, начала 00-х. Соответственно, они им привычней, удобней видеть интерфейс из того-же времени и плевать они хотели на современные стандарты и тенденции.
А приведите пример современных стандартов и тенденций в части визуализации АСУТП?
Я не отделял UI АСУ ТП от UI других информационных систем. А примеры привёл автор статьи. Думаю, вы сами, если посмотрите вокруг вполне в состоянии увидеть, какие пользовательские интерфейсы создаются в 2020 году.
Я не отделял UI АСУ ТП от UI других информационных систем.
В этом и кроется ошибка. Если почитать The High Performance HMI от Rockwell, то можно увидеть, что основной упор в интерфейсах делается на внимание к граничным и аварийным значениям. Если всё в порядке, то картинка максимально серая и невзрачная. И это оправдано, т.к. обычно диспетчеры круглые сутки смотрят в монитор, и всякие свистоперделки просто сведут с ума к концу смены.
а кто говорил про свистелки и перделки? я даже больше скажу. доморощенные мнемосхемы скада-систем порой представляют из себя даже не кашу, а настоящий борщ из условных гостовских обозначений, вырезанных или нарисованных в паинте картинок, похожих на какое-то оборудование, не несущее никакой полезной информации, бессмысленной анимации. И всё это в ядрёно-кислотных расцветках.
С точки зрения UX стоит всё-таки ответить сначала на вопрос «зачем нужна эта система?» Не стоит забывать, что в отличие от многого другого ПО SCADA обычно вещь вторичная относительно техпроцесса, который ею обслуживается.
Если цель системы, например, минимизация времени простоя, то один из вариантов представления с этой точки зрения может быть распределение на два потока — информационный и аварийный.
В первом случае нет определённого фокуса и система может отображать избыточную или общую информацию. Режим «всего понемногу, вдруг что-то будет любопытно».
В аварийном режиме интерфейс должен помочь оператору быстро идентифицировать, оценить последствия и решить конкретную проблему. И весьма вероятно решение будет ломом или гаечным ключом на месте аварии, а не кнопкой.
Ещё один аспект это иерархия, децентрализация системы и локальный контроль. На большом объекте можно иметь диспетчерскую со стеной из экранов, но те, кто работают в процессе производства должны иметь возможность принять решение на месте вместо того, что бы звонить диспетчерам. Это может означать появление отдельных устройств контроля-управления с уменьшенным функционалом. Это не всегда должны быть экраны и тач-скрин с цветами, шрифтами и иконками. Иногда проще и доступнее светофором, сиреной или АЗ/SCRAM с топором. Один из наглядных примеров — система управления нагрузкой на парковке. Датчик занятого места имеет локальный простой «выход» в виде красного/зелёного фонаря и он так же отчитывается «наверх» в систему, которая подсчитывает и выводит на экраны в проездах число свободных мест.
Если цель системы, например, минимизация времени простоя, то один из вариантов представления с этой точки зрения может быть распределение на два потока — информационный и аварийный.
В первом случае нет определённого фокуса и система может отображать избыточную или общую информацию. Режим «всего понемногу, вдруг что-то будет любопытно».
В аварийном режиме интерфейс должен помочь оператору быстро идентифицировать, оценить последствия и решить конкретную проблему. И весьма вероятно решение будет ломом или гаечным ключом на месте аварии, а не кнопкой.
Ещё один аспект это иерархия, децентрализация системы и локальный контроль. На большом объекте можно иметь диспетчерскую со стеной из экранов, но те, кто работают в процессе производства должны иметь возможность принять решение на месте вместо того, что бы звонить диспетчерам. Это может означать появление отдельных устройств контроля-управления с уменьшенным функционалом. Это не всегда должны быть экраны и тач-скрин с цветами, шрифтами и иконками. Иногда проще и доступнее светофором, сиреной или АЗ/SCRAM с топором. Один из наглядных примеров — система управления нагрузкой на парковке. Датчик занятого места имеет локальный простой «выход» в виде красного/зелёного фонаря и он так же отчитывается «наверх» в систему, которая подсчитывает и выводит на экраны в проездах число свободных мест.
Сделанная визуализация не так сильно зависит от Scada системы. Ну то-есть как повторить интерфейс с самых нижних картинок в той же мастерскаде (картинка в самом начале, над Везой и под Круг-2000) — я вполне себе представляю, это вполне себе работающая система.
Зачем пишу — Мне интересно как Вы реализовываете (планируете/могли бы спланировать) к примеру
Диспетчеризацию Наличия напряжения у конкретного магазина в торговом центре. с учетом постоянного изменения «нарезки». (ну допустим если брать не счётчики для технического учета, которые не всегда возможно ставить, а допустим приставки контактные)
Зачем пишу — Мне интересно как Вы реализовываете (планируете/могли бы спланировать) к примеру
Диспетчеризацию Наличия напряжения у конкретного магазина в торговом центре. с учетом постоянного изменения «нарезки». (ну допустим если брать не счётчики для технического учета, которые не всегда возможно ставить, а допустим приставки контактные)
не очень понял вопроса, можете чуть подробнее, можно в личку
Имею ввиду диспетчеризацию в торговом центре к примеру наличия напряжения в конкретной палатке\магазине.
С обязательным учетом того, что нарезка торгового центра на квадраты постоянно изменяется — арендаторы уходят, площади объединяются и дробятся.
То-есть как постоянное изменение мнемосхемы нарезки на участки.
С обязательным учетом того, что нарезка торгового центра на квадраты постоянно изменяется — арендаторы уходят, площади объединяются и дробятся.
То-есть как постоянное изменение мнемосхемы нарезки на участки.
Понял. Ну в этом случае нет смысла делать планировку, тут проще табличную форму сделать с редактируемыми комментариями. Вообще с планировкой не очень просто, это хорошо если все одноэтажное, можно только несущими стенами обозначить планировку, они не изменятся. Слишком много второстепенных стен, перегородок, подписей создадут кашу. На последних примерах здание 5-этажное, его сделали в профиль, но и тут есть нюансы, на разных этажах разное кол-во систем. На одном объекте очень много система АВК, дренаж, кнс, протечки и тд, и все только на -1 этаже. Поэтому это дело только опытным путем решается, иногда много времени очень на это уходит
ну и как то совсем безличностно, почему не описали железо и софт на котором все сделано…
Да и в целом темная тема проще для восприятия и меньше нагружает глаза, тем более при длительном использовании
Субъективно все это. Лично я от темных тем везде отказался, надоели, уже года два как наверное. И даже в автокаде у меня уже лет 10 фон белый, а не черный. Лично для меня — удобнее.
Что касается конкретно SCADA и других диспетчерских систем, на белом экране желтые и красные аварии видно сразу и издалека, даже если ты по коридору мимо проходил и заглянул.
Участвовал в разработке подобных систем отображения, основная и самая серьезная проблема не техническая, а психологическая. Т.к. у лиц ответственных за решения сильно различаются вкусы и представления о дизайне. И часто приходилось об колено ломать неплохие решения, потому что "ну вот не понравилось потому что кнопки слева"…
3d интерфейсы были бы куда полезнее и понятнее
В свое время занимался проектами реконструкции информационных систем на БЩУ АЭС. Есть два примера для сравнения. Возможно не совсем справедливо сравнивать коммерческую систему от фирмы AdAstra с небольшой самодельной SCADA от компании Ракурс. Но тут все дело в архитектуре и подходах. С одной стороны довольно сложная, местами избыточно, система от AdAstra с совершенно примитивным и не надёжным протоколом резервирования, которая периодически подвисала и падала. Опять же графический дизайн там оставлял желать много лучшего. для сравнения был знаком с интерфейсами SCADA на Финской Ловизе или Норвежской IFE. Очень приятное впечатление осталось и с точки зрения эргономики и архитектуры и надёжности. Так вот работая с хорошими парнями из Ракурс, я сделал интересный вывод, хочешь надёжно и красиво — пиши свою SCADA. Особенно, если речь идет о блоках АЭС. Если дёшево и приемлемо, но не очень надёжно (долгие звонки в техподдержку и постоянные заплатки) купи что то вроде TraceMode. Информация у меня 10 летней давности, прошу прощения, если за это время данный софт сильно улучшился и эволюционировал.
Треймоуд, к слову не развивающийся уже лет 10, никак не тянет на образец, ЛОЛ.
А самоделки еще хуже.
А дизайн — любая нормальная СКАДА позволяет делать _любой_ дизайн — делай себе библиотеку кастомных объектов. Лично я могу это утверждать на 100% про FactoryTalk, iFix, WinCC.
А самоделки еще хуже.
А дизайн — любая нормальная СКАДА позволяет делать _любой_ дизайн — делай себе библиотеку кастомных объектов. Лично я могу это утверждать на 100% про FactoryTalk, iFix, WinCC.
Не развитие Trace Mode это вполне понятное явление. Там особо развивать было нечего. Сама по себе архитектура этой SCADA была тупиковым направлением. Насчёт самоделок это я к тому, что есть примеры, когда разработчики, желая сэкономить на лицензия, делают свой узко специализированный продукт, под свое конкретное оборудование. И это не всегда плохо. В конечном итоге все зависит от пряморукости программистов, которые выполняют эту задачу. В целом, конечно, промышленные изделия, масштабируемые и кастомизируемые, являются более разумным решением.
Что не так с интерфейсами SCADA-систем
а держать в штате отдельного дизайнера для этих задач никто не станет.
На просторах фриланса я нашел дизайнера, чьи работы мне понравились, и мы с ним за 2 недели сделали неплохой интерфейс
дизайнер всю работу сделал в Photoshop, после чего мы нарезали все элементы по-отдельности и начали собирать в среде разработки для панели оператора.……… вся статика создается в Photoshop и подгружается единой картинкой, поверх которой отображаются все переменные и динамические объекты.
понятно… SCADA системам не хватает дизайнера с фотошопом…
так то в SCADA можно импортировать свои картинки (с той или иной степенью успешности)… и уж панели Weintek тем более…
да и важнее как SCADA ситема осуществляет сбор данных (сколько протоколов поддерживает), сколько тегов может провернуть, как хорошо и удобно переваривает алармы, как много трендов она проворачивает, умеет ли работать с внешними БД, умеет ли в резевирование, есть ли в ней возможность создавать свои библиотечные графические элементы, есть ли доступ из скриптов ко всем свойствам графических объектов, насколько хорошо работает подсистема скриптов, умеет ли графика рисовать на несколько экранов не подвешивая комп и т.д.
Весьма немного (я знаю только Газпром и Транснефть) заказчиков имеют корпоративный стандарт на оформление — каким цветом какие трубопроводы и линии электропередач отображать, каким цветом какие состояния выключателей и клапанов отображать и т.д. и т.п., чтоб на всех объектов конторы был примерно одинаковый интерфейс.
Остальным по-барабану… зато на ПНР любой мимокрокодил свое мнение ляпнет, что «этот зеленый не слишком зеленый… надо зеленей»…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что не так с интерфейсами SCADA-систем