Зачем SCADA, когда есть .NET?

[Romer]

У вас очень неверное представление SCADA, потому что говорить о том, что WPF является убийцей скада-систем, все равно что например сказать, что OpenGL (или DirectX) будет убийцей игр!
SCADA — это не только HMI, графика там только малая часть айсберга…

[Wedmer]

А как у вас обстоят дела с документацией? Одной статьи маловато будет.

[cmd]

На мой взгляд, то, что показано на скриншотах без особых усилий делается на WinForms.
без проблема делается с мета описанием UI.
А в чем принципиальная новизна вашей идеи и при чем тут WPF?

[HomoLuden]

WPF теоретически выигрывает у WinForms в данном случае возможностями декларативной сборки UI посредством некоего конфига. Также возможности ControlTemplate и DataTemplate, а также возможность в рантайме распарсить XAML с версткой UI может быть преимуществом.

[totuin]

Скады будут жить, потому что они ориентированны на свою ЦА — разработчиков и эксплуатационников систем АСУ. И среди них не так много которые с легкостью сделают это:

Теперь добавим на страницу элементы управления.

<UserControl x:Class=«ClientSample.Pages.HomePage»
xmlns=«schemas.microsoft.com/winfx/2006/xaml/presentation»
xmlns:x=«schemas.microsoft.com/winfx/2006/xaml»
xmlns:mc=«schemas.openxmlformats.org/markup-compatibility/2006»
xmlns:d=«schemas.microsoft.com/expression/blend/2008»
xmlns:clientSample=«clr-namespace:ClientSample»
xmlns:pHmiControls=«clr-namespace:PHmiClient.Controls;assembly=PHmiClient»
mc:Ignorable=«d»
d:DesignHeight=«300» d:DesignWidth=«300»
d:DataContext="{d:DesignInstance clientSample:PHmi, IsDesignTimeCreatable=True}">
/>
/>
<CheckBox
IsChecked="{Binding Path=IoDev.DigitalTag.Value, Mode=TwoWay}"
Content="{Binding Path=IoDev.DigitalTag.Description}"/>
<pHmiControls:NumericInput NumericTag="{Binding Path=IoDev.NumericTag}"/>

Все таки в качестве UI у большинства скад — визуальный графический редактор. И очень удобная система управления связыванием, анимацией, сигнализацией. Небольшие проекты можно накидать не применяя программирования вообще, а если необходимо применение скриптов — есть понятные мастера. Я говорю на примере с моей точки зрения лучшей системы визуализации — WinCC от сименса. Я понимаю неприятие программистами визуальных редакторов, но большинство АСУ-шников все таки не программисты, а инженеры

[s60]

они могут и большее, но только в крайних случаях… когда по-другому никак…

[totuin]

Очень немногие. Я Асушник 15 лет, работал во многих организациях. Настоящих программистов среди асушников очень мало. Да и опять таки не нужно им это. Работал с как говорится «оригинальными» сименсами. У них такая же история

[s60]

Очень немногие. Я Асушник 15 лет, ....

это ваши… короче везунчик… считай, что повезло, если ни разу не делал костыли и тем более зака всегда устраивал встроенный функционал…

[totuin]

Мне в основном приходилось делать небольшие системы. Но много, почти на потоке с небольшими изменениями. Сейчас обслуживаю действительно большую систему (электростанция 300Мвт). Контроллеры Simens S-400, и система АСУ разрабатывалась сименсом. На верхнем уровне WinCC. Честно говоря за полтора года работы не видел кода ни на верхнем ни на нижнем уровне, хотя лазить в программу приходится часто. Все сделано штатными средствами. Хотя может мне действительно везёт))).

[s60]

а в чем проблема? Открываем WinCC->GlobalScrip и в Project scripts (или как там оно) видим, что наваяли разработчики… это глобально, а так анимация на картинке может быть трех видов: VBScript, Cscript, какой-то там Dialog — смотрим где код а не диалог и… не говорим больше что не видели :)

Картинка

кстати было бы интересно как САМ сименс (вам российские сименсовцы делали ?) делает…

[totuin]

Неа, там только я один раз ковырялся. А у сименса там ничего нет. Вот что и интересно!!!.. Делали импортые сименсы (Турбины полностью их производства), перевод интерфейса корявый, время от времени настолько что приходится самим править, хотя и лень. На ревизию то же шведы приезжают целой толпой. Механы, асушники. Ну и проверяют конечно что бы мы там особо не развлекались.

[s60]

Мне… приходилось делать небольшие системы.… Сейчас обслуживаю действительно большую систему… система АСУ разрабатывалась сименсом.

так ты кто:
— разработчик?
— служба АСУ, на балансе которой чьи-то поделки?
— оператор-технолог, пользующийся GUI?

[totuin]

Последние полтора года — инженер Асуп на газотурбинной электростанции. До этого достаточно долго работал инженером — программистом на предприятии выпускающем силовое распределительное оборудование. Занимался разработкой систем Асуп для этого оборудования. АВР-ы, системы освещения и вентиляции. Ну и шабашки естественно. А там вообще зоопарк. От КНС до управления освещением стадиона в Сочи и местного рыбзавода. До этого была судовая автоматика, где мы наперекор желанию электромехаников, пытались внедрить контроллеры в автоматику судов))). Суда старые, механы такие-же, и боятся современной техники. В 2001 это было что то новое и неизведанное.

[s60]

… на свою ЦА — разработчиков и эксплуатационников систем АСУ. И среди них не так много которые с легкостью сделают это:

и не потому, что они… не могут… а потому что рисовать xml'ем это изврат… для ценителей…

[totuin]

Абсолютно согласен

[HomoLuden]

Места с подозрением на утечки памяти:

1. MainWindow.xaml — Ln 232 и Ln 466
   

   <Binding Path="Modules.Count">
   

   
   
2. class alarm_categories — свойство «name» — Биндинг на свойства этого класса с большой вероятностью будут утекать. Кроме того, грубое нарушение конвенции наименования C#. Избавляйтесь сразу от биндингов напрямую в DTO. Это очень плохо, особенно когда этот DTO генерируется по темплейту или БД! Замучаетесь в partial файлы дописывать всякую логику, команды и пр. — то, что должно быть во ViewModel.
   Нашел еще много мест с биндингами на DTO. Исправляйте сразу, а не то проведете немало бессонных ночей за профайлером памяти.
3. EditTrendCategory.xaml Ln 26 — Все биндинги к датаконтексту могут утекать
   

   <Grid DataContext="{Binding Path=Entity}">
   

   
   
4. AlarmCategories.xaml Ln99 — Если ReadOnlyCollection не имплементит INotifyPropertyChanged и если свойство Count не является DependencyProperty, то утечка скорее всего имеет место быть.
   

   <TextBlock Text="{Binding Path=Collection.Count, StringFormat={x:Static Loc:Res.TotalRowsStatus}}" Style="{StaticResource StatusTextBlockStyle}"/>
   

   
   
   


Наверняка есть еще что-то. Нет времени искать все проблемные места. Принцип общий такой: класс того, что находится непосредственно перед последней точкой в пути биндинга, или того, что лежит в DataContext (при пути без точек), должен имплементить INotifyPropertyChanged. Либо это должен быть наследник DependencyObject, а биндинг должен в качестве Source получать DependencyProperty. Иначе все контролы с таким биндингом и связанные с ними ресурсы XAML могут оставаться в памяти после выгрузки их родителей.

[segrus]

А электронная часть будет? Как это всё связать, например, с частотником в шкафу управления? А если шкафов десятки, а приборов в нём сотни, как организовать съём данных и управление, как сделать сеть? Тоже буду делать свою СКАДУ. Начальник мечтает)

[s60]

Тоже буду делать свою СКАДУ. Начальник мечтает)

зачем, если не секрет?

[gogolgrind]

И каким образом все связывается с полевым оборудованием? Используется OPC. Или что еще? Приложение берет данные из PostgreSQL сервера, это понятно, но как данные попадают в базу?

[sutasu]

Да, самое интересное в таком проекте — поддержка OPC, OPC DA, ModBus. Еще конфигуратор мнемосхем нужен. Архивы — смотреть историю по тренду…

[pseudobrain]

Да. Понятие SCADA не понято автором. Посмотрите на монстров с которыми я работал SPPA-T3000 (Siemens) или Sytem Platform (Wonderware), их функционал пишется годами огромной командой разработчиков, и их удобство в огромных проектах с тысячью контроллеров и сотней клиентов не поддается сравнению с тем что вы тут показали.
Правильнее было сказать «Я пытался поиграть с интерфейсами и нарисовать графики».

[s60]

даже так: я узнал, что у меня WPF и студиЯ
а за провокационное название статьи так и минус впаять…

[s60]

Понятие SCADA не понято автором.

это при то, что

Я работаю в компании, которая занимается автоматизацией производственных процессов. Знаком не по наслышке с программируемыми логическими контроллерами (PLC), человеко-машинным интерфейсом (HMI) и SCADA (диспетчерское управление и сбор данных).

почувтвовали глубину ж… пропасти…

[HomoLuden]

Я бы еще посоветовал подключить сборку Microsoft.Expression.Interactions и заменить статические Behavior'ы с AttachedProperty на инстансовые версии от Expression Blend SDK.

public class DoSomthngBehavior : Behavior<TextBox>
{

    protected override OnAttached()
    {
        AssociatedObject.Loaded += OnAssociatedObjectLoaded;
    }

}

<TextBox ...>

    <i:Interaction.Behaviors>
        <b:DoSomthngBehavior SomeProp="..."/>
    </i:Interaction.Behaviors>

</TextBox>

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

[HomoLuden]

Например, такой кейс.

<TextBox ...>

    <i:Interaction.Behaviors>
        <b:ClearTextBehavior x:Name="ClearMeBehavior" IsEnabled="{Binding IsFocused, RelativeSource={RelativeSource AncestorType=TextBox}}"/>
    </i:Interaction.Behaviors>

    <i:Interaction:Triggers>
        <ei:DataTrigger Binding="{Binding Text, RelativeSource={RelativeSource AncestorType=TextBox}}"
                                  Value="Clear me!">
              <ei:CallMethodAction TargetObject="{Binding ElementName="ClearMeBehavior"}" MethodName="ClearAssociatedObject"/>
        </ei:DataTrigger>
    </i:Interaction:Triggers>

</TextBox>

Преимущество: можно сослаться в триггерах по имени на бехэвиор; наследуется DataContext, можно в коде гулять по визщуальному дереву в поисках приаттаченных бехэвиоров и пр.
Недостатки: Нельзя выставить его свойство в сеттерах Style. Нужен доступ к контролу напрямую или через Template.
Если что непонятно, спрашивайте.