@wloochacz: czyli chcesz powiedzieć, że mamy się za to nie zabierać, ponieważ na podstawie ogólnikowych informacji wyszedłeś z założenia, że się nie znamy i nie poradzimy sobie z tym, a już tym bardziej powinniśmy rozumieć produkcję, a nie klienta dla którego to piszemy? 
Tak dokładnie; na podstawie tego co piszesz, mam wrażenie że nie do końca rozumiesz z czym się mierzysz.
Po prostu.
Ale spokojnie, w końcu się dowiesz.
Poza tym padło słowo klucz GANTT.
Diagram Gantta determinuje harmonogram.
A harmonogram na produkcji determinuje operacje technologiczne i normatywy czasowe dla operacji, ponieważ bez tego nie masz danych aby ten harmonogram w ogóle narysować, a co dopiero nim zarządzać...
I to póki co jest minimum i to tylko na etapie harmonogramowania.
Ty masz mierzyć postęp realizacji, a to z kolei wymaga kontekstu powyżej z zestawieniem rzeczywistych danych z hali produkcyjnej.
I to musisz zrobić na poziomie konkretnej operacji (a wiec konkretnej maszyn/gniada produkcyjnego), a potem agregować w górę do zlecenia produkcyjnego i być może jeszcze wyżej, do zamówienia.
Też tak robisz, że jak zleceniodawca (właściciel firmy) mówi ci jak system ma działać to go poprawiasz, że źle mówi, bo ty wiesz lepiej jak produkcja powinna wyglądać na podstawie doświadczenia?
Oczywiście.
Więcej - właśnie tego ode mnie się oczekuje. Czasem jest i tak, że nie realizuję jakiegoś wymagania zgodnie z życzeniem, ponieważ w danym kontekście jest ono z czapy.
Tak naprawdę klient ma to dokładnie w nosie, jak to jest zrobione - on ma pewne oczekiwania i wyobrażenia.
Te drugie są czasem sprzeczne z tymi pierwszymi...
A jedynego czego jestem pewien na pewno, to tego, że wymagania się zmienią.
Zatem trzeba to projektować tak, aby dało się to rozwijać i zmieniać - nic na sztywno, żadnego wiązania drutem, żadnych uproszczeń, które zemszczą się okrutnie w przyszłości.
Tylko raz miałem sytuację, gdzie szefowa UR stwierdziła, ze "nie interesuje mnie to, co ma Pan do powiedzenia na bazie Pańskich doświadczeń".
Ale jej prezes od razu dodał "a mnie bardzo interesuje, proszę kontynuować".
Zajmuję się tym tematem na poważnie od dawna i możesz mi wierzyć, że wiem o czym mówię.
Poza tym mam takie cholerne szczęście, że trafiają mi się tematy trudne lub bardzo trudne.
Co w pewien sposób może skazić mój osąd, nie wykluczam tego...
Zresztą, to chyba nie jest dobre miejsce na takie dyskusje.
Ponadto raczej za szeroko napisałem, ponieważ za mało wiem o Twoich wymaganiach.
Mógłbym pewnie pomóc, ale musiałbym rozmawiać z produkcją, a nie z programistami.
Ale tak z ciekawości to Ci powiem, że to co chce Twój klient (i dużo, dużo więcej), bazując na tym co napisałeś wcześniej, jest do zrobienia za ok. 10 tyś zł.
Jest w PL taki gotowy system rozwijany od dekad za śmieszne pieniądze i robi robotę. Wydajność bierze nie tylko z guzika start/stop, ale przede wszystkim z monitorowania sygnałów maszyny.
I tak, da się go podłączyć również do maszyn CNC - np. centr obróbczych, czy elektrodrążarek.
I nie, nie jest to mój system :)
Problem polega na tym, że nie pisze tutaj wszystkiego, ponieważ nie chce rozwiązać problemu ogarniania i rozumienia produkcji tylko chce rozwiązać problem komunikacji całego systemu.
Tylko, że to jest hmm... podstawa bez której nie bardzo da się dostarczyć wymagania podstawowe.
No i nie zdefiniowałeś co to znaczy w czasie rzeczywistym.
Bo dla Ciebie to może oznaczać system czasu rzeczywistego.
Ale dla szefa produkcji, to będą realne informacje z produkcji z dopuszczalnym opóźnieniem do np. pół godziny.
Dla kogoś, kto dostaje raporty produkcji po (powiedzmy) tygodniu i to raczej na pewno niekompletne i niewiarygodne, jest to i tak rewolucja w jakości danych.
Za dużo widziałem dużych i bardzo dużych fabryk prowadzonych dosłownie na zeszycie, aby nie wiedzieć o czym piszę.
Oraz za dużo widziałem produkcji prowadzonych w systemach klasy Optima, aby nie wiedzieć co Cię czeka.
Optima nie posiada TPP (bo wybacz, ale receptura/kompletacja wykorzystywana do generowania RW po przyjęciu PW z produkcji, to nie jest TPP.
Ale i Optima nie jest ERP, mimo że tak się nazywa.)
Zwróć uwagę, że te wszystkie proste systemy zarządzają produkcją w oparciu o magazyn.
Ale Ty masz chyba inne wymagania, bo gdyby były tak proste, to wystarczyłoby monitorować PW z produkcji i tyle.
Też byś dostał postęp realizacji zlecenia.
Bez względu jaka produkcja, jaki system, jakie zmienne pytam o technologie informowania użytkowników o stanie realizacji w czasie rzeczywistym.
Dostałeś odpowiedź; kolejka komunikatów i system reaktywny. Nie pasywny.
Skoro to .NET to SignalR, a jeśli nie chcesz pisać serwera to Mosquitto da radę aż nadto, zwłaszcza że od wersji 1.5.4 działa również natywnie z kanałem WebSocket i również pod Windows. A z kolei WS, daje nam możliwość konsumpcji komunikatów również z weba, co bywa mocno przydatne. No i jest jeszcze bardzo popularny RabbitMQ albo rozwiązania chmurowe - do wyboru do koloru.
Tylko to nie jest żadna odpowiedź, bo to jak wysłać to powiadomienie to najmniejszy problem.
Natomiast skąd te dane wziąć i jak je przetwarzać, to zupełnie inna para kaloszy.
Uważam, że to co napisał @jacek.placek na temat niepotrzebnego odświeżania stanu co 1 sek. ma sens. Kierownik nie zawsze siedzi przed komputerem, nie wpatruje się w monitor przez 8 godzin. A z tego można wywnioskować, że nie potrzeba "szaleństw".
Dlatego dla takiej osoby lepszym rozwiązaniem są komunikaty o sytuacjach wyjątkowych (powiadomienia również na telefonie, różnie - ja korzystam ze Slacka, maila, SMS - różnie) oraz system, dzięki któremu łatwo i szybko sprawdzi co się dzieje i dlaczego. Lepszym, ponieważ nie gapi się w to cały dzień, a powinien wiedzieć o sytuacjach wyjątkowych.
Ponadto taki dashboard i tak jest potrzeby, ponieważ mimo tego ze nie wgapia się w to, to będzie chciał jednym spojrzeniem zobaczyć i dowiedzieć się "co w tej chwili dzieje się na produkcji".
Na cóż, zakładasz że tylko kierownik będzie to oglądał (bo pewnie tak Ci powiedział).
A ja się założę, że nie tylko on, ale również inne osoby w firmie i to w różnych agregacjach danych.
Ale to może kiedyś, poza tym znowu uprzedzam przyszłe wymagania...
Pracownik również nie powinien widzieć swojego stanu pracy, żeby go nie kusić. System upraszcza się do guzików "start", "stop".
Hmm... mam absolutnie inne zdanie na ten temat.
Moim klientom guziki start/stop przestały wystarczać po kilku tygodniach.
I nie wyobrażam sobie, aby gdziekolwiek było inaczej, kiedy dowiedzą się że może być inaczej.
Ale powiedz - padło pytanie "a czy ten system pokaże mi OEE"? :)
