Terminy i definicje systemów zautomatyzowanych. Wymagania dotyczące wsparcia organizacyjnego zautomatyzowanych systemów sterowania

GOST 24.104-85 Zautomatyzowane systemy sterowania. Wymagania ogólne (sekcja 3 zastąpiona przez GOST 34.603-92) Sekcja 3 zastąpiona przez GOST 34.603-92 Dekretem Państwowego Komitetu ds. Standardów ZSRR z dnia 20 grudnia 1985 r. nr 4632 ustalono datę wprowadzenia

od 01.01.1987r

Niniejsza norma ma zastosowanie do zautomatyzowanych systemów sterowania (ACS) wszystkich typów (z wyjątkiem krajowych) i ustanawia ogólne wymagania dla ACS jako całości, funkcji ACS, szkolenia personelu i rodzajów wsparcia ACS, bezpieczeństwa i ergonomii, typów i procedury badań przy uruchomieniu ACS, kompletność zautomatyzowanego systemu sterowania, gwarancje.

Norma nie określa wymagań dla zautomatyzowanych systemów sterowania uwarunkowanych specyfiką obiektów sterowania. Wymagania te są sformułowane w specyfikacjach technicznych dotyczących tworzenia lub rozwoju każdego zautomatyzowanego systemu sterowania lub w innych dokumentach regulacyjnych i technicznych działu klienta zautomatyzowanego systemu sterowania.

Dodatkowe wymagania dotyczące zautomatyzowanych systemów sterowania procesami technologicznymi, zautomatyzowanych systemów sterowania dla przedsiębiorstw, stowarzyszeń przemysłowych i naukowo-produkcyjnych oraz zautomatyzowanych systemów sterowania dla danej branży określone są odpowiednio w obowiązkowych załącznikach 1-3.

Odniesienie Dodatek 4 zawiera wyjaśnienia niektórych terminów używanych w standardzie.

1. WYMAGANIA DLA ACS

1.1. Ogólne wymagania dotyczące zautomatyzowanego systemu sterowania

1.1.1. Zautomatyzowany system sterowania dowolnego typu musi spełniać wymagania niniejszej normy, wymagania specyfikacji technicznych dotyczących jego tworzenia lub rozwoju (zwane dalej specyfikacjami technicznymi zautomatyzowanego systemu sterowania), a także wymagania regulacyjne i dokumenty techniczne obowiązujące w dziale klienta zautomatyzowanego systemu sterowania.

1.1.2. Uruchomienie zautomatyzowanych systemów sterowania powinno prowadzić do użytecznych wyników technicznych, ekonomicznych, społecznych lub innych, na przykład:

• zmniejszenie liczby personelu kierowniczego;
• poprawa jakości funkcjonowania obiektu kontroli;
• poprawa jakości zarządzania itp.

1.1.3. Specyficzna treść wymagań określonych w ust. 1.1.2, 1.1.5-1.1.11, 1.2, 1.3, 1.4.2, 1.4.3, 1.4.6, 1.4.9, 1.5.2, 1.5.4, 1.5.6, 1.5.7, 1.6. 2, 1.6.6, 1.6.12, 1.7.2, 1.7.3 są zainstalowane w specyfikacjach technicznych zautomatyzowanego systemu sterowania.

1.1.4. Zautomatyzowany system sterowania musi zapewniać osiągnięcie celów jego powstania (rozwoju) określonych w SIWZ dla zautomatyzowanego systemu sterowania.

1.1.5. Zautomatyzowany system sterowania musi zapewniać kompatybilność pomiędzy swoimi częściami, a także z systemami zautomatyzowanymi (AS) połączonymi z tym zautomatyzowanym systemem sterowania.

W przypadkach, gdy na bazie sieci komputerowej tworzony jest zautomatyzowany system sterowania lub zespół zautomatyzowanych systemów sterowania (AS), należy zastosować wielopoziomowe systemy protokołów interakcji, aby zapewnić kompatybilność pomiędzy elementami takiej sieci.

1.1.6. Zautomatyzowany system sterowania jako całość i wszystkie rodzaje jego wsparcia muszą być przystosowane do modernizacji, rozwoju i rozbudowy w granicach wymagań określonych w specyfikacji istotnych warunków zamówienia na zautomatyzowany system sterowania.

1.1.7. Niezawodność zautomatyzowanego systemu sterowania jako całości i każdej z jego zautomatyzowanych funkcji musi być wystarczająca do osiągnięcia założonych celów działania systemu w danych warunkach aplikacyjnych.

1.1.8. Możliwości adaptacyjne zautomatyzowanego układu sterowania muszą być wystarczające, aby osiągnąć założone cele jego działania w danym zakresie zmian warunków stosowania.

1.1.9. SCS musi zapewniać monitorowanie prawidłowego działania funkcji automatycznych i diagnostykę, wskazując lokalizację, rodzaj i przyczynę naruszeń prawidłowego funkcjonowania ACS.

1.1.10. SCS posiadające kanały pomiarowe muszą mieć możliwość kontrolowania właściwości metrologicznych kanałów pomiarowych.

1.1.11. Zautomatyzowany system sterowania musi zapewniać zabezpieczenia przed nieprawidłowymi działaniami personelu prowadzącymi do stanu awaryjnego obiektu lub systemu sterowania, przed przypadkowymi zmianami i zniszczeniem informacji i programów, a także przed nieupoważnioną ingerencją.

1.1.12. Wszelkie informacje wprowadzane do SSO wprowadzane są do systemu jednorazowo jednym kanałem wejściowym, chyba że prowadzi to do niespełnienia wymagań określonych w specyfikacjach technicznych SSO (niezawodność, niezawodność itp.).

1.1.13. Informacja wyjściowa o tej samej treści semantycznej musi zostać wygenerowana w zautomatyzowanym systemie kontroli jednorazowo, niezależnie od liczby odbiorców.

1.1.14. Informacje zawarte w bazach ACS muszą być aktualizowane zgodnie z częstotliwością ich wykorzystania podczas wykonywania funkcji systemu.

1.1.15. Zautomatyzowany system sterowania musi być chroniony przed wyciekiem informacji, jeżeli jest to określone w specyfikacjach technicznych zautomatyzowanego systemu sterowania.

1.1.16. Nazwa ACS musi zawierać nazwę typu ACS i obiektu sterującego.

Na przykład:

• Układ sterowania procesem nagrzewania metalu w piecu metodycznym;
• system zautomatyzowanego sterowania organizacyjno-technologicznego w warsztacie nr 5;
• Automatyczny system sterowania fabryką Młotów i Sierpów

1.2. Wymagania dla funkcji ACS

1.2.1. Zautomatyzowany system kontroli w wymaganym zakresie musi w sposób automatyczny wykonywać:

• zbieranie, przetwarzanie i analiza informacji (sygnałów, komunikatów, dokumentów itp.) o stanie obiektu kontroli;
• opracowywanie działań kontrolnych (programy, plany itp.);
• przekazywanie czynności kontrolnych (sygnały, instrukcje, dokumenty) wykonania i jego kontrola;
• wdrażanie i kontrola działań kontrolnych;
• wymiana informacji (dokumentów, wiadomości itp.) z połączonymi ze sobą zautomatyzowanymi systemami.

1.2.2. Skład zautomatyzowanych funkcji (zadań, zestawów zadań – zwanych dalej funkcjami) zautomatyzowanego systemu sterowania musi zapewniać możliwość sterowania odpowiednim obiektem zgodnie z którymkolwiek z celów określonych w specyfikacjach technicznych zautomatyzowanego systemu sterowania.

1.2.3. Skład zautomatyzowanych funkcji zautomatyzowanego systemu sterowania oraz stopień ich automatyzacji muszą być uzasadnione technicznie, ekonomicznie i (lub) społecznie, biorąc pod uwagę potrzebę uwolnienia personelu od wykonywania powtarzalnych czynności i stworzenia warunków do wykorzystania jego kreatywności umiejętności w procesie pracy.

1.3. Wymagania dotyczące gotowości personelu systemów automatycznego sterowania

1.3.1. Kwalifikacje personelu ACS muszą zapewniać skuteczne funkcjonowanie systemu we wszystkich określonych trybach.

1.3.2. Personel ACS musi być przygotowany do wykonywania swoich obowiązków zgodnie z instrukcjami wsparcia organizacyjnego.

1.3.3. Każda osoba wchodząca w skład personelu zautomatyzowanego systemu sterowania ma obowiązek stosować odpowiednie modele informacyjne oraz pracować z używanymi przez nią środkami technicznymi i dokumentacją, które określają tryb jej działań.

1.4. Wymagania dotyczące wsparcia technicznego zautomatyzowanych systemów sterowania

1.4.1. Kompleks środków technicznych zautomatyzowanego systemu sterowania musi być wystarczający do wykonania wszystkich zautomatyzowanych funkcji zautomatyzowanego systemu sterowania.

1.4.2. Zespół środków technicznych zautomatyzowanych systemów sterowania powinien wykorzystywać głównie środki techniczne produkcji masowej. W razie potrzeby dozwolone jest zastosowanie środków technicznych pojedynczej produkcji.

1.4.3. Replikowane systemy automatycznego sterowania i ich części muszą być budowane w oparciu o ujednolicone środki techniczne.

1.4.4. Środki techniczne ACS muszą być umieszczone zgodnie z wymaganiami zawartymi w ich dokumentacji technicznej, w tym eksploatacyjnej, oraz w taki sposób, aby można było z nich wygodnie korzystać podczas eksploatacji ACS i wykonywania konserwacji.

1.4.5. Rozmieszczenie środków technicznych używanych przez personel zautomatyzowanego systemu sterowania podczas wykonywania zautomatyzowanych funkcji musi spełniać wymagania ergonomiczne: dla urządzeń produkcyjnych zgodnie z GOST 12.049-80, dla środków prezentacji informacji wizualnej zgodnie z GOST 21829-76, w tym dla tablic do użytku zbiorowego wykonane z cyfrowych wskaźników elektroluminescencyjnych syntetyzujących znaki zgodnie z GOST 21837-76.

1.4.6. Środki techniczne zautomatyzowanego systemu sterowania stosowane w interakcji zautomatyzowanego systemu sterowania z innymi systemami muszą być kompatybilne w interfejsach z odpowiednimi środkami technicznymi tych systemów i stosowanymi systemami komunikacji.

1.4.7. Zautomatyzowany system kontroli musi wykorzystywać środki techniczne o żywotności co najmniej dziesięciu lat. Stosowanie środków technicznych o krótszej żywotności dopuszczalne jest tylko w uzasadnionych przypadkach i po uzgodnieniu z klientem zautomatyzowanego systemu sterowania.

1.4.8. Każdy ze środków technicznych zautomatyzowanego układu sterowania musi umożliwiać jego zastąpienie środkiem o podobnym przeznaczeniu funkcjonalnym bez jakichkolwiek zmian konstrukcyjnych lub dostosowań w pozostałych środkach technicznych zautomatyzowanego układu sterowania (z wyjątkiem przypadków szczegółowo określonych w dokumentacji technicznej automatyczny system kontroli).

1.4.9. Środki techniczne ACS mogą być stosowane wyłącznie na warunkach określonych w ich dokumentacji eksploatacyjnej. W przypadku konieczności ich stosowania w środowisku, którego parametry przekraczają dopuszczalne wartości ustalone dla tych środków technicznych, należy przewidzieć środki zabezpieczające poszczególne środki techniczne zautomatyzowanego systemu sterowania przed wpływem czynników zewnętrznych.

1.4.10. Zautomatyzowany system sterowania musi wykorzystywać technologię komputerową spełniającą ogólne wymagania techniczne zgodnie z GOST 22552-84.

1.4.11. Zautomatyzowany system kontroli musi wykorzystywać środki techniczne odpowiadające:

• dla odporności na czynniki zewnętrzne - GOST 12997-76 dla urządzeń przemysłowych i urządzeń automatyki GSP, GOST 14254-80 dla powłok wyrobów elektrotechnicznych, GOST 17516-72 dla wyrobów elektrotechnicznych w zakresie wpływu mechanicznych czynników środowiskowych, GOST 21552-84 w zakresie technologii sprzętu komputerowego;
• dla parametrów mocy - GOST 12997-76 dla urządzeń przemysłowych i urządzeń automatyki GSP, GOST 21552-84 dla sprzętu komputerowego;
• według kategorii wydajności - GOST 12997-76 dla urządzeń przemysłowych i sprzętu automatyki GSP, GOST 21552-84 dla sprzętu komputerowego.

1.4.12. Ochrona środków technicznych układu automatycznego sterowania przed wpływem zewnętrznych pól elektrycznych i magnetycznych oraz zakłóceniami w obwodach zasilających musi być wystarczająca, aby środki techniczne mogły skutecznie spełniać swoje zadanie podczas pracy układu automatycznego sterowania.

1.4.13. W ACS, zgodnie z wymogami określonymi w „Ogólnounijnych normach dopuszczalnych zakłóceń przemysłowych” 1-72 - 9-72 i GOST 23450-79, należy zapewnić środki w celu ochrony środowiska zewnętrznego przed przemysłowymi zakłóceniami radiowymi emitowanymi przez środków technicznych ACS podczas pracy oraz w momencie włączania i wyłączania.

1.4.14. Ogólne wymagania ergonomiczne dotyczące diagramów mnemonicznych - zgodnie z GOST 21480-76, dla urządzeń zliczających dla wskaźników wizualnych - zgodnie z GOST 22902-78, dla tablic zbiorczego użytku na cyfrowych wskaźnikach elektroluminescencyjnych syntetyzujących znaki - zgodnie z GOST 21837-76, dla promieni katodowych tuby do wyświetlania informacji wizualnej - zgodnie z GOST 23144-78.

1.4.15. Ogólne wymagania ergonomiczne dotyczące przełączników na pulpitach sterowniczych: przełączniki obrotowe - zgodnie z GOST 22613-77, przełączniki klawiaturowe i przyciskowe - zgodnie z GOST 22614-77, typu „Przełącznik” - zgodnie z GOST 22615-77.

1.4.16. Ogólne wymagania ergonomiczne dotyczące dźwiękowych alarmów z komunikatem głównym są zgodne z GOST 21786-76.

1.4.17. Ogólne wymagania ergonomiczne regulujące organizację miejsca pracy, odpowiednie rozmieszczenie urządzeń wyświetlających informacje, sterowanie i komunikację w miejscu pracy - zgodnie z GOST 22269-76, w tym piloty - zgodnie z GOST 23000-76.

1.4.18. Ogólne wymagania ergonomiczne dotyczące krzeseł operatora zgodnie z GOST 21889-76.

1.4.19. Ogólne wymagania ergonomiczne dotyczące hali, kabin operatorów i odpowiedniego rozmieszczenia siedzeń są zgodne z GOST 21958-76.

1,5. Wymagania oprogramowania ACS

1.5.1. Oprogramowanie ACS musi być wystarczające do realizacji wszystkich funkcji ACS realizowanych przy użyciu technologii komputerowej, a także posiadać środki do zorganizowania wszystkich wymaganych procesów przetwarzania danych, umożliwiając terminową realizację wszystkich zautomatyzowanych funkcji we wszystkich regulowanych trybach pracy ACS.

1.5.2. Oprogramowanie ACS musi posiadać następujące właściwości:

• wystarczalność funkcjonalna (kompletność);
• niezawodność (w tym możliwość odtwarzania, dostępność narzędzi do wykrywania błędów);
• zdolność adaptacji;
• modyfikowalność;
• modułowość konstrukcji i
• łatwość użycia.

1.5.3. Oprogramowanie ACS powinno być budowane przede wszystkim w oparciu o istniejące pakiety oprogramowania aplikacyjnego i inne programy pożyczone od rządu, przemysłu i innych funduszy algorytmów i programów, umożliwiać ładowanie i sprawdzanie części oraz umożliwiać wymianę niektórych programów bez poprawiania innych.

1.5.4. Zautomatyzowany system kontroli powinien przede wszystkim wykorzystywać systemy zarządzania bazami danych (DBMS), zarejestrowane w określony sposób.

1.5.5. Oprogramowanie ACS musi być zbudowane w taki sposób, aby brak poszczególnych danych nie miał wpływu na działanie funkcji ACS, przy realizacji których dane te nie są wykorzystywane.

1.5.6. Oprogramowanie ACS musi posiadać narzędzia do diagnozowania sprzętu ACS i monitorowania wiarygodności informacji wejściowych.

1.5.7. Oprogramowanie ACS musi wdrożyć środki zabezpieczające przed błędami podczas wprowadzania i przetwarzania informacji, zapewniające określoną jakość wykonywania funkcji ACS.

1.5.8. Oprogramowanie ogólne zautomatyzowanego systemu sterowania powinno umożliwiać konfigurację specjalnych elementów oprogramowania i dalszy rozwój oprogramowania zautomatyzowanego systemu sterowania, nie zakłócając procesu jego funkcjonowania. Wygenerowaną i załadowaną już część oprogramowania należy chronić przed przypadkowymi zmianami.

1.5.9. Wszystkie specjalne programy dla określonego zautomatyzowanego systemu sterowania muszą być kompatybilne zarówno między sobą, jak i z jego ogólnym oprogramowaniem.

1.5.10. Dokumentacja oprogramowania operacyjnego dla zautomatyzowanego systemu sterowania musi być zgodna ze standardami ESPD i zawierać wszelkie informacje niezbędne personelowi zautomatyzowanego systemu sterowania do korzystania z oprogramowania, jego wstępnego załadowania i (lub) wygenerowania, załadowania informacji z wewnętrznej bazy informacji o maszynie, uruchomienia zautomatyzowanego programy systemów sterowania i sprawdzanie ich funkcjonowania za pomocą odpowiednich testów.

1.5.11. Nowo opracowane podczas tworzenia konkretnego zautomatyzowanego systemu kontroli produkty oprogramowania zawarte w jego oprogramowaniu muszą być zarejestrowane w państwie, branży lub innym funduszu algorytmów i programów (w stosownych przypadkach).

1.6. Wymagania dotyczące wspomagania informacyjnego zautomatyzowanych systemów sterowania

1.6.1. Wsparcie informacyjne zautomatyzowanego systemu sterowania musi być wystarczające do wykonania wszystkich zautomatyzowanych funkcji zautomatyzowanego systemu sterowania.

1.6.2. Do zakodowania informacji wykorzystywanych wyłącznie w danym systemie automatyki należy zastosować klasyfikatory zaakceptowane przez klienta systemu automatyki.

1.6.3. Aby zakodować informację wyjściową wykorzystywaną na wyższym poziomie w ACS, należy zastosować klasyfikatory systemów sterowania wyższego poziomu, z wyjątkiem specjalnie określonych przypadków.

1.6.4. Ogólne wymagania ergonomiczne dotyczące kodowania informacji są zgodne z GOST 21829-76.

1.6.5. W zautomatyzowanym systemie sterowania do komunikacji pomiędzy urządzeniami kompleksu środków technicznych należy zastosować:

• sygnały wejściowe i wyjściowe:
  • elektryczne - prąd i napięcie według GOST 26.011-80, z dyskretnymi zmianami parametrów zgodnie z GOST 26.013-81, kodowane według GOST 26.014-81,
  • hydrauliczny zgodnie z GOST 26.012-80,
  • pneumatyczny zgodnie z GOST 26.015-81;
• zestawy znaków alfanumerycznych zgodnie z GOST 19767-74;
• Kody 8-bitowe zgodnie z GOST 19768-74.

1.6.6. Wspomaganie informacyjne zautomatyzowanego systemu sterowania musi być kompatybilne z wspomaganiem informacyjnym współpracujących z nim systemów pod względem treści, systemu kodowania, sposobów adresowania, formatów danych oraz formy prezentacji informacji otrzymywanych i wydawanych przez zautomatyzowany system sterowania.

1.6.7. Formy dokumentów tworzone przez zautomatyzowany system kontroli muszą być zgodne z wymogami standardów USD lub dokumentów regulacyjnych i technicznych działu klienta zautomatyzowanego systemu kontroli.

1.6.8. Formy dokumentów i klatek wideo wprowadzanych, wyprowadzanych lub korygowanych za pośrednictwem terminali ACS muszą być zgodne z odpowiednimi parametrami technicznymi terminali.

1.6.9. Całość tablic informacyjnych zautomatyzowanych systemów sterowania musi być zorganizowana w formie baz danych na nośnikach komputerowych.

1.6.10. Formę prezentacji informacji wyjściowej zautomatyzowanego systemu sterowania należy uzgodnić z klientem (użytkownikiem) systemu.

1.6.11. Terminy i skróty stosowane w dokumentach wyjściowych zautomatyzowanego systemu sterowania muszą być ogólnie przyjęte w danej dziedzinie tematycznej i uzgodnione z klientem systemu.

1.6.12. Zautomatyzowany system kontroli musi zapewniać niezbędne środki do kontroli i aktualizacji danych w tablicach informacyjnych zautomatyzowanego systemu kontroli, przywracania tablic po awarii jakichkolwiek środków technicznych zautomatyzowanego systemu kontroli, a także kontroli tożsamości informacji o tej samej nazwie w bazach danych.

1.7. Wymagania dotyczące wsparcia organizacyjnego zautomatyzowanych systemów sterowania

1.7.1. Wsparcie organizacyjne zautomatyzowanego systemu kontroli musi być wystarczające do skutecznego wykonywania przez personel zautomatyzowanego systemu kontroli powierzonych mu obowiązków w zakresie realizacji zautomatyzowanych obowiązków w zakresie wdrażania zautomatyzowanych i powiązanych niezautomatyzowanych funkcji systemu.

1.7.2. Struktura organizacyjna zautomatyzowanego systemu kontroli musi umożliwiać realizację wszystkich funkcji zautomatyzowanego systemu kontroli, z uwzględnieniem ich podziału pomiędzy szczeble zarządzania.

1.7.3. Wymagania dotyczące podziału obowiązków wśród personelu zaangażowanego w obsługę zautomatyzowanego systemu kontroli w czasie rzeczywistym ustala się z uwzględnieniem wymagań punktu 11 obowiązkowego dodatku 1.

1.7.4. Instrukcje wsparcia organizacyjnego zautomatyzowanego systemu sterowania muszą określać działania personelu zautomatyzowanego systemu sterowania niezbędne do wykonania każdej funkcji zautomatyzowanej we wszystkich trybach pracy zautomatyzowanego systemu sterowania, biorąc pod uwagę określone wymagania dotyczące dokładności i szybkości realizacji przez personel zautomatyzowanego systemu sterowania o jego obowiązkach funkcjonalnych, a także zawierają szczegółowe instrukcje dotyczące postępowania w przypadku wystąpienia sytuacji awaryjnych lub naruszenia normalnych warunków pracy zautomatyzowanego systemu sterowania. Wymagania dotyczące treści instrukcji są zgodne z GOST 24.209-80.

1.7.5. Dla każdej zautomatyzowanej funkcji, która jest wykonywana w interakcji tego ACS z innymi systemami, instrukcje dla personelu ACS i tych systemów muszą być ze sobą powiązane dla wszystkich trybów wykonywania tej funkcji i zawierać instrukcje dotyczące działań personelu w przypadku awarii środki techniczne ACS.

1.8. Wymagania dotyczące obsługi językowej zautomatyzowanych systemów sterowania

1.8.1. Wsparcie językowe zautomatyzowanego systemu sterowania musi być wystarczające do komunikacji pomiędzy różnymi kategoriami użytkowników w dogodnej dla nich formie z narzędziami automatyzacji zautomatyzowanego systemu sterowania oraz do przeprowadzenia procedur przetwarzania i maszynowej reprezentacji informacji przetwarzanych w zautomatyzowanym systemie sterowania.

1.8.2. Wsparcie językowe zautomatyzowanego systemu sterowania powinno obejmować:

• zapewnione są narzędzia językowe umożliwiające opisanie wszelkich informacji wykorzystywanych w zautomatyzowanym systemie kontroli;
• użyte środki językowe są ujednolicone;
• ujednolicono opisy podobnych elementów informacji i zapis struktur syntaktycznych;
• Zapewniona jest wygoda, jednoznaczność i stabilność komunikacji pomiędzy użytkownikami a zautomatyzowanymi systemami sterowania;
• zapewnione są środki umożliwiające korygowanie błędów powstających, gdy użytkownicy komunikują się ze środkami technicznymi zautomatyzowanego systemu kontroli.

1.8.3. Wsparcie językowe zautomatyzowanego systemu sterowania musi znaleźć odzwierciedlenie w dokumentacji (instrukcjach, opisach) wsparcia organizacyjnego zautomatyzowanego systemu sterowania w postaci zasad komunikacji między użytkownikami i środkami technicznymi zautomatyzowanego systemu sterowania we wszystkich trybach systemu operacja.

1.9. Wymagania dotyczące obsługi prawnej zautomatyzowanych systemów sterowania

Wsparcie prawne zautomatyzowanych systemów sterowania powinno obejmować zbiór norm prawnych:

• ustalanie ważności prawnej informacji znajdujących się na nośnikach danych i dokumentach wykorzystywanych w funkcjonowaniu zautomatyzowanego systemu kontroli i tworzonych przez ten system;
• regulujące stosunki prawne pomiędzy osobami wchodzącymi w skład personelu ACS (prawa, obowiązki i odpowiedzialność), a także pomiędzy personelem ACS a personelem systemów współpracujących z ACS.

Notatka. Zasady i regulacje wynikające z ważności prawnej informacji na nośnikach danych oraz regulacje prawne muszą być zawarte w instrukcjach wsparcia organizacyjnego i regulaminach odpowiednich usług ICS.

1.10. Wymagania dotyczące dokumentacji eksploatacyjnej zautomatyzowanych systemów sterowania

1.10.1. Dokumentacja eksploatacyjna ACS musi być wystarczająca do uruchomienia ACS i jego skutecznego funkcjonowania.

1.10.2. Dokumentacja eksploatacyjna zautomatyzowanego systemu sterowania musi:

• zawierać informacje niezbędne do szybkiego i wysokiej jakości rozwoju oraz prawidłowego działania zautomatyzowanych systemów sterowania;
• zawierać instrukcje dotyczące działań personelu ACS w sytuacjach awaryjnych lub w przypadku naruszenia normalnych warunków pracy ACS;
• nie zawierać przepisów podlegających dwuznacznej interpretacji.

2. WYMOGI BEZPIECZEŃSTWA

2.1. Nieprawidłowe działania personelu ACS nie powinny prowadzić do sytuacji awaryjnej.

2.2. Wymagania bezpieczeństwa dla produktów elektrycznych stosowanych w zautomatyzowanych systemach sterowania są zgodne z GOST 12.2.007.0-75.

2.3. Wymagania bezpieczeństwa dla sprzętu komputerowego stosowanego w zautomatyzowanych systemach sterowania są zgodne z GOST 25861-83.

2.4. Wszystkie zewnętrzne elementy środków technicznych automatycznego układu sterowania, które są pod napięciem, muszą być chronione przed przypadkowym kontaktem, a same środki techniczne muszą być uziemione lub uziemione zgodnie z GOST 12.1.030-81 i „Przepisy dotyczące urządzeń zasilających” .

2.5. Urządzenia techniczne ACS zlokalizowane w instalacjach zagrożonych wybuchem i pożarem muszą spełniać wymagania „Przepisów Zasilanie”.

2.6. Środki techniczne ACS należy instalować w sposób zapewniający ich bezpieczną eksploatację i konserwację.

2.7. Wymagania bezpieczeństwa muszą być określone w specjalnej sekcji opisów stanowisk i (lub) instrukcji obsługi zautomatyzowanych systemów sterowania i zawierać łącza do instrukcji obsługi urządzeń technicznych.

2.8. Ogólne wymagania ergonomiczne dotyczące stanowisk pracy personelu zautomatyzowanych systemów sterowania są zgodne z GOST 22269-76.

2.9. Komfortowe warunki życia personelu zautomatyzowanego systemu sterowania muszą odpowiadać aktualnym normom sanitarnym, maksymalne dopuszczalne warunki życia - zgodnie z GOST 12.1.005-76, dopuszczalne poziomy wpływu niebezpiecznych i szkodliwych czynników produkcyjnych - zgodnie z GOST 12.0.003-74 .

2.10. Ogólne wymagania ergonomiczne dotyczące mikroklimatu pomieszczeń roboczych personelu zautomatyzowanego systemu sterowania są zgodne z GOST 12.1.005-76.

2.11. Poziomy hałasu i mocy akustycznej w miejscach przebywania personelu zautomatyzowanego systemu sterowania nie powinny przekraczać wartości ustalonych w GOST 12.1.003-83 i normach sanitarnych, natomiast poziomy hałasu i mocy akustycznej wytwarzane przez wszystkie źródła, w tym środki akustyczne transmisji danych, należy wziąć pod uwagę.

2.12. Poziom oświetlenia stanowisk pracy personelu automatyki musi odpowiadać charakterowi i warunkom pracy. Należy zapewnić ochronę przed olśnieniem i redukcję olśnienia.

2.13. Ogólne wymagania ergonomiczne dotyczące wibracji sprzętu na stanowiskach pracy personelu zautomatyzowanego systemu sterowania są zgodne z GOST 12.1.012-78.

2.14. Kolory sygnalizacyjne i znaki bezpieczeństwa zgodnie z GOST 12.4.026-76.

3. RODZAJE I PROCEDURA BADAŃ PRZY URUCHOMIENIU SKR

Niniejsza sekcja dotyczy wszystkich zautomatyzowanych systemów sterowania, z wyjątkiem tych stworzonych na zlecenie Ministerstwa Obrony.

3.1. Zautomatyzowany system sterowania lub oddzielnie dostarczana funkcja zautomatyzowanego systemu sterowania (zwana dalej zautomatyzowanym systemem sterowania) w momencie uruchomienia musi przejść badania wstępne i akceptacyjne oraz badania przewidziane w dokumentach regulacyjnych i technicznych obowiązujące w dziale Klienta zautomatyzowanego systemu sterowania.

3.2. Testy odbiorcze zautomatyzowanego systemu sterowania muszą być poprzedzone jego próbnym uruchomieniem na sterowni.

3.3. Testy ACS przeprowadzane są zgodnie z dokumentem „Program testów”, który jest przygotowywany przez twórcę ACS. Wymagania dotyczące treści programu testowego są zgodne z GOST 24.208-80.

3.4. Badania ACS można przeprowadzić jedno lub kilkuetapowo.

Na podstawie wyników badań ACS sporządza „Raport z badań”. Wymagania dotyczące treści raportu z badań są zgodne z GOST 24.208-80.

Przy badaniu SPS krok po kroku, „Raport z badań” sporządzony na podstawie wyników poprzedniego etapu powinien zawierać wniosek o możliwości poddania ACS do kolejnego etapu badań.

3.5. Wstępne testy zautomatyzowanego układu sterowania

3.5.1. Przeprowadzane są badania wstępne automatu, mające na celu określenie jego działania i rozstrzygnięcie kwestii możliwości dopuszczenia automatu do pracy próbnej.

3.5.2. „Program testów” do wstępnego testowania ACS jest zatwierdzany przez klienta ACS.

3.5.3. Wstępne testy ACS organizowane są przez klienta i przeprowadzane wspólnie przez twórcę ACS i klienta.

3.5.4. Prowizja za przeprowadzenie testów wstępnych zautomatyzowanego systemu sterowania ustalana jest na zlecenie klienta. Na przewodniczącego komisji powoływany jest przedstawiciel klienta zautomatyzowanego systemu kontroli.

3.5.6. „Raport z badań”, sporządzony na podstawie wyników wstępnych badań SPS, zawiera wnioski dotyczące możliwości dopuszczenia SPS do eksploatacji próbnej, a także listę niezbędnych modyfikacji i zalecane terminy ich wdrożenia.

3.6. Próbne działanie zautomatyzowanych systemów sterowania

3.6.1. Wyniki przyjęcia ACS do eksploatacji próbnej dokumentowane są w „Świadectwie odbioru do eksploatacji próbnej”, sporządzonym na podstawie „Raportu z badań” przez komisję, która przeprowadziła wstępne testy ACS. Wymagania dotyczące treści ustawy są zgodne z GOST 24.208-80.

3.6.2. Na czas próbnej pracy zautomatyzowanego systemu sterowania składa się czas niezbędny do sprawdzenia prawidłowości działania zautomatyzowanego systemu sterowania przy wykonywaniu każdej zautomatyzowanej funkcji oraz gotowość personelu zautomatyzowanego systemu sterowania do udziału w wykonywaniu wszystkich zautomatyzowanych funkcji zautomatyzowany system kontroli.

3.6.3. Minimalny czas pracy próbnej zautomatyzowanego układu sterowania (z wyjątkiem automatycznego układu sterowania) przed testem odbiorczym ustalany jest dla każdej przedłożonej zautomatyzowanej funkcji zautomatyzowanego układu sterowania; musi on odpowiadać wartościom wskazanym w tabela. Jeżeli łączny czas trwania przerw w ciągłości działania automatu przekracza wartość podaną w tabeli, należy kontynuować pracę próbną do czasu uzyskania wyników zgodnych z tabelą lub do chwili podjęcia decyzji o jej zakończeniu.

Dopuszcza się, po uzgodnieniu z klientem, poddanie ACS testom akceptacyjnym bez próbnego działania tych zautomatyzowanych funkcji, których częstotliwość rozwiązywania jest mniejsza niż raz w miesiącu, pod warunkiem, że w ACS nie tylko takie funkcje są zautomatyzowane.

Częstotliwość automatycznego wykonywania funkcji	Minimalny czas pracy próbnej zautomatyzowanego systemu sterowania przed testami odbiorczymi	Dopuszczalny łączny czas trwania zakłóceń w ciągłości wykonywania funkcji zautomatyzowanego systemu sterowania
Bez przerwy	1 miesiąc	Nie więcej niż 3 dni
Raz dziennie lub częściej	To samo	Nie więcej niż 10% planowanej liczby rozwiązań
Rzadziej niż raz dziennie do raz w miesiącu	3 miesiące	To samo
Rzadziej niż raz w miesiącu do raz na sześć miesięcy	Okres pomiędzy dwiema kolejnymi decyzjami	Niedopuszczalne są zakłócenia ciągłości wykonywania funkcji
Raz na rok lub rzadziej	Okres czasu potrzebny na przetestowanie przyjętej technologii gromadzenia i przetwarzania informacji podczas jednorazowej realizacji funkcji ACS	To samo

Uwagi:

1. Za naruszenie ciągłości wykonywania funkcji automatyki zautomatyzowanego układu sterowania uważa się jej niewykonanie w terminie określonym w dokumentacji technicznej zautomatyzowanego układu sterowania, chyba że jest to spowodowane naruszeniem warunki pracy zautomatyzowanego układu sterowania lub obiektu regulacji.

2. Jeżeli rzeczywisty czas pracy próbnej zautomatyzowanego systemu sterowania był dłuższy niż czas wskazany w drugiej kolumnie tabeli, wówczas łączny czas trwania zakłócenia ciągłości wykonania każdej z zautomatyzowanych funkcji ustala się za okres czasu wskazanych w tabeli i bezpośrednio poprzedzających badania odbiorcze.

3.6.4. Podczas próbnej pracy ACS prowadzony jest dziennik pracy, w którym zapisywane są informacje: o czasie pracy ACS, o wynikach monitorowania prawidłowego funkcjonowania ACS, o awariach, awariach, sytuacjach awaryjnych, o zmianach w parametrach obiektu kontroli i bieżących korektach dokumentacji technicznej.

3.6.5. Na podstawie wyników eksploatacji próbnej wystawiane jest świadectwo zakończenia prac nad sprawdzeniem zautomatyzowanego układu sterowania w trybie pracy próbnej. Wymagania dotyczące treści ustawy są zgodne z GOST 24.208-80.

3.7. Testy akceptacyjne ACS

3.7.1. Badania odbiorcze ACS przeprowadzane są w celu ustalenia jego zgodności ze specyfikacjami technicznymi ACS, wymaganiami niniejszej normy oraz określenia możliwości oddania ACS do eksploatacji.

3.7.2. W zależności od wagi obiektu kontroli i zautomatyzowanego systemu sterowania, badania akceptacyjne mogą być:

• rząd;
• międzyresortowy;
• oddziałowy

i muszą być przeprowadzane przez odpowiednie komisje akceptacyjne. Komitet odbiorczy tworzony jest na zlecenie ministerstwa (departamentu) klienta zautomatyzowanego systemu sterowania. Poziom komisji odbiorczej musi być określony w specyfikacjach technicznych zautomatyzowanego systemu sterowania.

3.7.3. Na przewodniczącego komisji odbiorczej powoływany jest przedstawiciel klienta zautomatyzowanego systemu sterowania. W komisji odbiorczej muszą znajdować się przedstawiciele dewelopera ACS.

3.7.4. Praca komisji odbiorczej nie obejmuje odbiorów budynków, budowli i urządzeń pomocniczych, których powstanie zostało przeprowadzone w związku ze stworzeniem zautomatyzowanego systemu sterowania. Komisja sprawdza jedynie dostępność świadectw dopuszczenia do eksploatacji i spełnienia wymagań zawartych w zadaniach projektowych w sąsiadujących częściach projektu obiektu, wydanych podczas projektowania układu automatyki.

3.7.5. Klient i deweloper przedstawiają komisji odbiorczej następującą dokumentację:

• zakres zadań i obowiązków dotyczących stworzenia zautomatyzowanego systemu kontroli;
• projekt programu testów akceptacyjnych;
• Wstępny raport z testów ACS;
• świadectwo przyjęcia zautomatyzowanego układu sterowania do pracy próbnej;
• akt(a) po zakończeniu prac nad sprawdzeniem zautomatyzowanego układu sterowania w trybie pracy próbnej;
• dokumentacja techniczna zautomatyzowanego systemu sterowania (decyzją komisji odbiorczej).

3.7.6. Zautomatyzowane układy sterowania wraz z kanałami pomiarowymi przed poddaniem do badań odbiorczych poddawane są certyfikacji metrologicznej zgodnie z obowiązującymi normami.

3.7.7. Przed przedstawieniem ACS do badań odbiorczych należy sfinalizować system i jego dokumentację techniczną w oparciu o uwagi zawarte w protokole badań wstępnych oraz zaświadczenie o zakończeniu prac związanych ze sprawdzeniem ACS w trybie pracy próbnej.

Dopuszcza się, decyzją komisji odbiorczej, sfinalizowanie dokumentacji technicznej zautomatyzowanego systemu sterowania po jego uruchomieniu. Terminy ukończenia dokumentacji technicznej zautomatyzowanego systemu sterowania wskazane są w protokole z testów odbiorczych systemu.

3.7.8. Testy akceptacyjne zautomatyzowanego systemu sterowania należy przeprowadzić w funkcjonującym obiekcie kontrolnym.

3.7.9. „Program testów” dotyczący testów akceptacyjnych zautomatyzowanego systemu sterowania musi zostać zatwierdzony decyzjami komisji akceptacyjnej. Koordynacja programu testów odbiorczych z klientem zautomatyzowanego systemu sterowania jest obowiązkowa.

3.7.10. Na podstawie wyników badań odbiorczych komisja sporządza protokół z badań oraz ustawę o oddaniu SN do eksploatacji (lub wniosek o nieodbiorze UST z wykazem niezbędnych zmian i zalecanymi terminami ich wdrożenia). Wymagania dotyczące treści protokołu i postępowania zgodnie z GOST 24.208-80. Wymagania dotyczące treści postanowienia o odmowie przyjęcia zautomatyzowanego systemu kontroli są podobne do wymagań dotyczących treści ustawy o wprowadzeniu zautomatyzowanego systemu kontroli.

3.7.11. W przypadku etapowych testów akceptacyjnych akt uruchomienia zautomatyzowanego systemu sterowania sporządzany jest na podstawie aktów uruchomienia poszczególnych części systemu i (lub) „Raportów z testów” wszystkich etapy testów akceptacyjnych zautomatyzowanego systemu sterowania.

3.7.12. Za datę uruchomienia zautomatyzowanego układu sterowania uważa się datę podpisania aktu uruchomienia przez komisję odbiorczą.

3.7.13. Ustawę o wprowadzeniu w życie zautomatyzowanego systemu kontroli zatwierdza ministerstwo (departament) klienta.

4. KOMPLETNOŚĆ ODDAWANEGO DO URUCHOMIENIA SPRZĘTU

4.1. AZS powinien zawierać:

• Środki techniczne ACS w postaci kompleksu środków technicznych ACS przygotowanych do eksploatacji;
• części zamienne i urządzenia (SPTA), przyrządy i urządzenia do badania sprawności, ustawiania urządzeń technicznych i monitorowania charakterystyk metrologicznych kanałów pomiarowych zautomatyzowanego układu sterowania w zakresie przewidzianym w dokumentacji projektowej na zamówienie uzgodnionej z klientem automatu system kontroli i obsługa metrologiczna użytkownika w zakresie sprzętu badawczego;
• dokumentacja operacyjna zgodna z GOST 2.601-68 dla każdego z produktów wchodzących w skład CTS ACS;
• co najmniej dwie kopie programów na nośnikach danych i dokumentacja operacyjna na nich zgodnie z GOST 19.101-77, z uwzględnieniem ograniczeń i uzupełnień zgodnie z GOST 24.101-80 i GOST 24.207-80;
• formularz dla oprogramowania ACS jako całości lub dla oprogramowania funkcji ACS uruchomionego osobno oraz formularze dla oprogramowania (zgodnie z GOST 19.004-80), każdy w jednym egzemplarzu. Wymagania dotyczące formularza - zgodnie z GOST 19.501-78;
• dwa egzemplarze dokumentacji operacyjnej zautomatyzowanego systemu sterowania zgodnie z GOST 24.101-80, w tym niezbędna dokumentacja do wsparcia informacyjnego zautomatyzowanego systemu sterowania (formularz zautomatyzowanego systemu sterowania w jednym egzemplarzu).

W drodze porozumienia między twórcą ACS a klientem ACS kompletność ACS może zostać rozszerzona.

4.2. Personel ACS musi składać się z personelu spełniającego wymagania punktu 1.3.

4.3. Do uzupełnienia utworzonego zautomatyzowanego systemu sterowania można zastosować, dostarczane jako produkty produkcyjne i techniczne:

• kompleks (kompleksy) sprzętu i oprogramowania wraz z dokumentacją operacyjną dla nich zgodnie z GOST 2.601-68;
• produkty programowe wraz z dokumentacją operacyjną dla nich zgodnie z GOST 19.101-77;
• wyposażenie techniczne wraz z dokumentacją eksploatacyjną do nich zgodnie z GOST 2.601-68.

4.4. Procedura opracowywania, uruchamiania do produkcji i testowania dostarczonych elementów stosowanych w zautomatyzowanym systemie sterowania musi być zgodna z normami państwowymi dotyczącymi systemu rozwoju i wprowadzania wyrobów do produkcji.

Prototypy komponentów przed wprowadzeniem do produkcji poddawane są badaniom odbiorczym (państwowym, międzywydziałowym, wydziałowym).

5. GWARANCJA

5.1. Twórca automatu gwarantuje zgodność automatu z wymaganiami niniejszej normy oraz specyfikacjami technicznymi automatu, pod warunkiem przestrzegania przez użytkownika warunków i zasad eksploatacji.

5.2. Zgodność sprzętu, oprogramowania i systemów urządzeń automatyki stosowanych w układach automatyki, dostarczanych jako wyroby produkcyjne i techniczne z wymaganiami norm i specyfikacji dla nich, gwarantują producenci tego typu wyrobów, pod warunkiem przestrzegania przez użytkownika wymagań eksploatacyjnych warunki i zasady.

5.3. Okres gwarancji na ACS liczony jest od dnia oddania ACS do użytku.

5.4. Okres gwarancji na ACS musi być określony w specyfikacjach technicznych ACS i nie może być krótszy niż 18 miesięcy.

ANEKS 1
Obowiązkowy

DODATKOWE WYMAGANIA DLA ZAUTOMATYZOWANYCH SYSTEMÓW KONTROLI PROCESÓW (APS)

1. Systemy sterowania procesami w przemyśle i pozaprzemysłowym muszą zarządzać obiektem technologicznym jako całością i dostarczać połączonym systemom rzetelną informację technologiczną i techniczno-ekonomiczną o funkcjonowaniu obiektu sterowania technologicznego (TOU).

2. Zautomatyzowany system sterowania procesem musi opracowywać i wdrażać racjonalne pod względem celów i kryteriów sterowania działania kontrolne na systemie sterowania technicznego w czasie rzeczywistym procesu technologicznego w obiekcie sterowania.

3. Zautomatyzowany system sterowania procesem musi spełniać funkcje kontrolne, informacyjne i pomocnicze.

4. System sterowania procesem musi być kompatybilny ze wszystkimi połączonymi z nim systemami automatyki (AS), określonymi w SIWZ systemu sterowania procesem, w tym z systemami wchodzącymi w skład tego systemu sterowania procesem w ramach elastycznej zautomatyzowanej produkcji, np. Technologie CAD, zautomatyzowane systemy magazynowe i transportowe, AS do technologicznego przygotowania produkcji.

5. Działania kontrolne w zautomatyzowanym systemie sterowania procesami muszą być generowane automatycznie lub generowane przez jego obsługę za pomocą zestawu narzędzi automatyzacji zawartych w systemie.

6. Zautomatyzowany system sterowania procesem musi zapewniać kontrolę obiektu w normalnych, przejściowych i przedawaryjnych warunkach jego funkcjonowania, a także ochronę lub wyłączenie obiektu w przypadku zagrożenia awarią.

7. Zautomatyzowany system kontroli procesów musi pełnić funkcję monitorowania wykonywania czynności kontrolnych na urządzeniach technicznych i sygnalizować osiągnięcie przez organy wykonawcze maksymalnych dopuszczalnych pozycji.

8. Realizując funkcję awaryjnego automatycznego odchylenia urządzeń w systemie sterowania procesem, należy powiadomić obsługę o tym alarmując za pomocą sygnałów świetlnych i, w razie potrzeby, dźwiękowych z automatyczną rejestracją czasu wyłączenia.

9. Jako główne środki techniczne zautomatyzowanych systemów sterowania procesami powinny być produkty Państwowego Systemu Przyrządów Przemysłowych i Sprzętu Automatyki (GSP), inne produkty spełniające wymagania norm ESSP oraz sprzęt komputerowy zgodny z GOST 21552-84 używany.

10. Środki techniczne systemów zautomatyzowanego sterowania procesami, umieszczone na urządzeniach procesowych, muszą spełniać wymagania dotyczące warunków ich pracy.

11. Podział odpowiedzialności pomiędzy operatorami powinien uwzględniać:

• udział personelu w wykonywaniu ręcznych funkcji systemu i jego interakcji z innymi systemami;
• dopuszczalny poziom obciążenia psychofizjologicznego i emocjonalnego operatorów, ustalony w branżowych dokumentach normatywnych i technicznych, związany z wykonywaniem powierzonych każdemu z nich obowiązków oraz jego odpowiedzialnością za końcowe i pośrednie wyniki pracy, a także wymagany poziom jego aktywności w trakcie pracy.

12. Każda osoba wchodząca w skład personelu musi posiadać:

• wiedza, której wielkość i głębokość pozwala mu wykonywać działania (interakcje) zawarte w odpowiednich zautomatyzowanych i wzajemnie powiązanych niezautomatyzowanych funkcjach zautomatyzowanego systemu sterowania procesami, a także podejmować właściwe decyzje w sytuacjach awaryjnych lub innych naruszeniach normalnego funkcjonowania ;
• rozwinięte umiejętności, które pozwalają na wykonywanie wszelkich czynności i interakcji z określoną dokładnością i szybkością.

13. Oprogramowanie systemu zautomatyzowanego sterowania procesami musi zapewniać, a wsparcie organizacyjne musi odzwierciedlać narzędzia językowe umożliwiające komunikację personelu operacyjnego z systemem zautomatyzowanego sterowania procesami, wygodne i dostępne dla osób nie posiadających kwalifikacji programisty.

14. Kody i symbole stosowane w systemie sterowania procesem powinny być zbliżone do terminów i pojęć używanych przez personel technologiczny obiektu sterowania i nie powinny powodować trudności w ich odbiorze.

15. Kanały pomiarowe zautomatyzowanego systemu kontroli procesu muszą posiadać właściwości metrologiczne zapewniające realizację jego funkcji informacyjnych ze wskaźnikami określonymi w specyfikacjach technicznych zautomatyzowanego systemu kontroli procesu.

16. Wymagania dotyczące badania zautomatyzowanych systemów sterowania procesami

16.1. Wstępne testy zautomatyzowanego systemu sterowania procesem przeprowadzane są na istniejącym sprzęcie technicznym.

16.2. Wstępne testy funkcji zautomatyzowanego systemu sterowania procesem niezbędne do uruchomienia i docierania urządzeń procesowych można przeprowadzić na miejscu za pomocą symulatorów.

16.3. Określenie rzeczywistych wartości wskaźników efektywności technicznej i ekonomicznej oraz niezawodności zautomatyzowanego systemu sterowania procesem następuje po jego uruchomieniu. Czas pracy zautomatyzowanego systemu sterowania procesem, niezbędny do ustalenia rzeczywistych wartości jego wskaźników, oblicza się według odpowiednich metod zatwierdzonych w zalecany sposób.

ZAŁĄCZNIK 2
Obowiązkowy

DODATKOWE WYMAGANIA DLA ACS PRZEZ PRZEDSIĘBIORSTWA, PRODUKCYJNO-BADAWCZE ORAZ STOWARZYSZENIA PRODUKCYJNE

1. Zautomatyzowany system kontroli musi zwiększać efektywność działalności produkcyjnej i gospodarczej przedsiębiorstw, stowarzyszeń produkcyjnych lub stowarzyszeń naukowo-produkcyjnych (zwanych dalej przedsiębiorstwami).

2. System automatycznego sterowania przedsiębiorstwa (ACS) musi zapewniać zautomatyzowane gromadzenie i przetwarzanie informacji przy powszechnym stosowaniu metod optymalizacyjnych dla głównych zadań i podsystemów sterowania na poziomie ogólnym zakładu i warsztatu, w tym, jeśli to konieczne, w czasie rzeczywistym w teleprzetwarzaniu i tryb dialogowy.

3. Zautomatyzowany system sterowania musi być realizowany jako zbiór wspólnie funkcjonujących podsystemów, których interakcja musi odbywać się poprzez wspólną (pojedynczą lub rozproszoną) bazę danych.

4. Wsparcie organizacyjne zautomatyzowanych systemów kontroli powinno zapewniać doskonalenie metod zarządzania i struktury systemu zarządzania przedsiębiorstwem podczas tworzenia i rozwoju zautomatyzowanych systemów kontroli.

ZAŁĄCZNIK 3
Obowiązkowy

DODATKOWE WYMAGANIA DLA PRZEMYSŁOWYCH AUTOMATYCZNYCH SYSTEMÓW STEROWANIA (OACS)

1. OASU musi zapewnić:

• doskonalenie cech obiektu kontroli (zwiększanie wydajności pracy w branży, poprawa jakości produktów, terminowość dostaw produktów, obniżenie kosztów wytwarzanych produktów);
• doskonalenie procesów przetwarzania informacji (obniżenie kosztów przetwarzania informacji, zwiększenie wiarygodności procesów początkowych, zwiększenie dokładności i efektywności obliczeń);
• doskonalenie organizacji funkcji zarządzania (w szczególności racjonalny podział pracy pomiędzy działami aparatu zarządzającego, centrami komputerowymi oraz organizacjami badawczymi i przedsiębiorstwami).

2. OASU musi zautomatyzować funkcje zarządzania branżą, na przykład:

• prognozowanie i planowanie produkcji i zasobów przemysłu;
• zarządzanie rozwojem naukowo-technicznym przemysłu i technicznym przygotowaniem produkcji przemysłowej;
• zarządzanie personelem w branży;
• zarządzanie zasobami materialnymi przemysłu;
• zarządzanie budową kapitału w przemyśle;
• zarządzanie zasobami finansowymi branży;
• zarządzanie, w tym zarządzanie operacyjne, produkcją główną na poziomie branżowym itp.

3. OACS powinien być wdrażany jako zbiór wspólnie funkcjonujących podsystemów, których interakcja powinna odbywać się poprzez wspólne bazy danych.

4. OASU musi posiadać system gromadzenia danych oparty na centrach komputerowych OASU, organizacjach i przedsiębiorstwach z branży, zapewniający racjonalną dystrybucję informacji w bazach danych w celu rozwiązywania współdziałających problemów oraz przesyłania informacji pomiędzy systemami za pośrednictwem kanałów komunikacyjnych i mediów komputerowych.

5. OACS musi zapewniać interaktywny tryb pracy z systemowymi bazami danych.

6. Utworzenie OASU powinno prowadzić do udoskonalenia metod i struktury zarządzania przemysłem.

7. Czas próbnego działania części OACS musi zapewniać jednorazowe wykonanie wszystkich obliczeń niezbędnych do realizacji zautomatyzowanych funkcji wprowadzonej części OACS i nie powinien przekraczać 3 miesięcy.

Konkretny czas próbnej pracy OASU ustalany jest w drodze umowy pomiędzy deweloperem a klientem.

ZAŁĄCZNIK 4
Informacja

OBJAŚNIENIE NIEKTÓRYCH TERMINÓW STOSOWANYCH W NINIEJSZEJ STANDRZE

Zespół urządzeń automatyki (CAS)- dostarczony zestaw wzajemnie uzgodnionych zestawów sprzętu komputerowego i oprogramowania (produktów), opracowany i wyprodukowany jako produkt do celów przemysłowych i technicznych. KSA może obejmować także inne produkty i (lub) dokumenty zawarte w wsparciu informacyjnym, organizacyjnym lub innego rodzaju dla zautomatyzowanych systemów.

Rozbudowa zautomatyzowanych systemów sterowania- zespół działań podejmowanych w zautomatyzowanym systemie sterowania przy rozbudowie jego obiektu sterowania bez zmiany składu funkcji zautomatyzowanego systemu sterowania.

Klatka wideo (w ACS)- obraz na ekranie kineskopu, dokument rysunku lub tekstu komunikatu wykorzystywanego w zautomatyzowanym systemie sterowania.

Kanał pomiarowy ACS- funkcjonalnie zintegrowany zestaw narzędzi technicznych i (jeśli to konieczne) programowych, zaprojektowany do realizacji jednej prostej funkcji pomiarowej zautomatyzowanego systemu sterowania.

Wstępne testy zautomatyzowanego układu sterowania- przeprowadzone badania kontrolne w celu ustalenia możliwości dopuszczenia zautomatyzowanego układu sterowania do pracy próbnej.

Testy akceptacyjne ACS- badania kontrolne zautomatyzowanego systemu sterowania, przeprowadzane w celu ustalenia jego zgodności z warunkami technicznymi tworzenia zautomatyzowanego systemu sterowania, wymaganiami norm oraz w celu określenia możliwości uruchomienia zautomatyzowanego systemu sterowania.

Testy stanowe- badania odbiorcze zautomatyzowanych systemów sterowania prowadzone przez komisję państwową.

Testy międzywydziałowe- testy akceptacyjne zautomatyzowanych systemów sterowania przeprowadzone przez komisję złożoną z przedstawicieli kilku zainteresowanych ministerstw i (lub) departamentów.

Testy wydziałowe- testy akceptacyjne zautomatyzowanych systemów sterowania przeprowadzone przez komisję złożoną z przedstawicieli zainteresowanego ministerstwa lub departamentu.

Redaktor AI Lomina
Redaktor techniczny N.P. Zamołodczikowa
Korektor E.I. Ewtejewa
Dostarczono do zestawu 16.01.86. Podpisano do publikacji 08.04.86. Warunkowy piekarnik l. 1,5. Warunkowy cr.-ott. 1.5 Wyd. akademickie. l. 1,5.
Nakład 40 000 Cena 10 kopiejek.
Zamów „Odznakę honorową” Wydawnictwo standardów, 123810, Moskwa, GSP, ulica Novopresnensky, 3
Typ. „Drukarka Moskiewska”, Moskwa, ulica Lyalin, 6. Rozkaz 1772

Dzisiaj porozmawiamy o krajowych standardach dotyczących dokumentacji projektowej. Jak te standardy działają w praktyce, dlaczego są złe i dlaczego są dobre. Opracowując dokumentację dla klientów rządowych i poważnych klientów prywatnych, zwykle nie mamy wyboru - zgodność z normami wpisuje się w wymagania dotyczące dokumentowania specyfikacji technicznych. W praktyce spotkałem się z różnymi przykładami niezrozumienia konstrukcji norm, tego, co powinno znajdować się w dokumentach i po co te dokumenty są potrzebne. W rezultacie pióra pisarzy technicznych, analityków i specjalistów produkują czasami takie perełki, że nie jest jasne, w jakim stanie świadomości zostały napisane. Ale tak naprawdę wszystko jest dość proste. Wyszukiwanie w serwisie Habr nie przyniosło żadnych linków do mniej lub bardziej kompletnych materiałów na ten temat, dlatego proponuję uzupełnić tę irytującą lukę.

Jakie są standardy dokumentacji?

W omawianej serii 34 istnieją tylko 3 główne standardy dokumentacyjne:

Najbardziej ukochany i popularny standard opracowywania specyfikacji technicznych. Jedyną rzeczą, o której nie należy zapominać, jest to, że jest ona ściśle powiązana z innymi normami serii i jeśli otrzymałeś specyfikacje techniczne opracowane zgodnie z tą normą, zdecydowanie zaleca się przestrzeganie innych norm, nawet jeśli nie ma bezpośrednich wymagań dla tego. Przynajmniej pod względem ogólnej ideologii (o której poniżej)

Jest to podstawowy dokument zawierający pełną listę dokumentacji GOST 34, zalecenia dotyczące kodowania dokumentów, do jakich etapów projektu należą dokumenty (etapy opisano w GOST 34.601-90), a także w jaki sposób można je ze sobą łączyć .

W rzeczywistości ten standard to duża tabela z komentarzami. Dla ułatwienia można go umieścić w Excelu.

Obszerny standard opisujący zawartość dokumentów projektowych z różnym stopniem szczegółowości. Jako indeks stosuje się wyżej wymieniony GOST 34.201-89.

Pojawia się wiele pytań i interpretacji jej zapisów dotyczących normy RD 50-34.698-90, które ze względu na swoją niejasność są często odmiennie rozumiane przez klienta i wykonawcę, czy nawet członków zespołu projektowego. Ale niestety nie mamy nic bardziej konkretnego.

Rozważmy teraz zalety i wady standardów, tradycyjnie zaczynając od wad.

Wady standardów

Główna wada jest oczywista dla wszystkich - standardy są stare. Zawierają przestarzałą koncepcję architektury zautomatyzowanego systemu. Na przykład:

• aplikacje dwuwarstwowe, składające się z programu klienckiego i serwera DBMS (żadnych aplikacji trójwarstwowych lub więcej, żadnych aplikacji Weblogic ani JBoss)
• opisana struktura tabel bazy danych da wyobrażenie o logicznym modelu danych (fakt, że pomiędzy aplikacją a bazą danych może występować jakiś rodzaj hibernacji wydawał się wtedy złym nadużyciem)
• interfejs użytkownika jest jednookienkowy (czy jest coś jeszcze? Co to jest „przeglądarka”?)
• Raportów w systemie jest niewiele, wszystkie są papierowe i drukowane na drukarce igłowej.
• Opracowywany program koncentruje się na rozwiązaniu „problemu przetwarzania informacji”, który ma jasne dane wejściowe i wyjściowe oraz jest wysoce wyspecjalizowany. Przetwarzanie informacji opiera się na „algorytmie”. Czasami istnieje kilka „algorytmów”. (Programowanie obiektowe dopiero wtedy stawiało pierwsze kroki i nie było poważnie brane pod uwagę).
• administrator bazy danych rozumie, jakie informacje znajdują się w tabelach i aktywnie uczestniczy w edycji katalogów systemowych (czy naprawdę istnieje jeden serwer DBMS dla 50 różnych aplikacji?)

W związku z tym standard zawiera następujące artefakty:

5.8. Rysunek formularza dokumentu (klatka wideo)
Dokument musi zawierać obraz formy dokumentu lub klatki wideo zgodnie z wymogami norm państwowych jednolitego systemu dokumentacji R 50-77 oraz niezbędne wyjaśnienia.

Rzecz w tym, że radzieckie przedsiębiorstwa korzystały z tzw. „Obszarów Drukowania”, gdzie znajdowały się szybkie drukarki igłowe, do których sterowniki często pisali sami inżynierowie. Dlatego musieli prowadzić rejestr wszystkich dokumentów, które należało wydrukować, aby mieć pewność, że po wydrukowaniu dokumenty wyglądają tak, jak powinny.

„Klatka wideo” to także dokument, który został wyświetlony na wyświetlaczu tekstowym. Wyświetlacze nie zawsze obsługiwały wymagane znaki oraz wymaganą liczbę znaków poziomych i linii pionowych (a w ogóle nie obsługiwały grafiki). Dlatego i tutaj konieczne było dodatkowe skoordynowanie form wszystkich dokumentów ekranowych.

Teraz słowa „machineogram”, „ramka wideo”, „ADC” nic nam już nie mówią. Ja też nie znalazłem ich w użyciu, chociaż ukończyłem specjalistyczny instytut w latach 90-tych. Był to czas pojawienia się systemu Windows 3.1, wyświetlaczy VGA, trzycalowych dyskietek i pierwszych krajowych witryn internetowych. Ale te słowa są w standardzie, a klient czasami kapryśnie żąda, abyśmy dostarczyli mu komplet dokumentacji zgodnie z GOST 34.201-89. Co więcej, takie sformułowania w SIWZ migrują z ministerstwa do ministerstwa i stały się już rodzajem niewypowiedzianego szablonu, w który wbija się treść.

Zatem dokument o głupiej nazwie „Rysunek formularza dokumentu (klatka wideo)” w projekcie powinien i nie powinien być pusty.

Co dobrego w standardzie

Każdy standard jest dobry, ponieważ pozwala zamawiającemu i wykonawcy mówić tym samym językiem i daje gwarancję, że przynajmniej klient nie będzie miał żadnych skarg „w formie” na przesłane wyniki.

Standardy GOST 34 są również dobre, ponieważ zostały opracowane przez inteligentnych ludzi, testowane przez lata i mają jasny cel - możliwie najpełniejsze opisanie na papierze złożonej abstrakcyjnej istoty, jaką reprezentuje każdy zautomatyzowany system sterowania.

Kiedy trzeba kompetentnie postawić zadanie zachodnim wykonawcom, którzy nigdy nie słyszeli o naszych standardach GOST, można też polegać na tych standardach, a raczej na ich merytorycznym i semantycznym elemencie. Ponieważ, powtarzam, gwarancja kompletności informacji jest wiele warta. Bez względu na to, jak bardzo pochlebiamy sobie wysokim poziomem naszego profesjonalizmu, możemy zapomnieć o uwzględnieniu elementarnych rzeczy w naszych wymaganiach, podczas gdy ten sam GOST 34.602-89 „pamięta” wszystko. Jeśli nie jest dla Ciebie jasne, jak powinien wyglądać efekt pracy zachodnich wykonawców, zapoznaj się z wymogami dokumentacji i zalecanymi sekcjami. Zapewniam, że lepiej o tym nie myśleć! Najprawdopodobniej istnieją zachodnie odpowiedniki naszych standardów, w których wszystko może być pełniejsze, nowocześniejsze i lepsze. Niestety nie znam ich, ponieważ nie było jeszcze ani jednego przypadku, w którym nasze standardy GOST byłyby niewystarczające.

Można się śmiać z tego, że twórcy standardów nie mieli zielonego pojęcia o Javie, .NET, monitorach HD i Internecie, ale nie radziłbym lekceważyć skali wykonanej przez nich pracy i jej wartości dla naszej społeczności zawodowej.

Jak czytać i rozumieć standardy dokumentacji według GOST seria 34

Norma dzieli wszystkie dokumenty wzdłuż dwóch osi – czasowej i przedmiotowej. Jeśli spojrzysz na tabelę 2 w GOST 34.201-89, wyraźnie zobaczysz ten podział (kolumny „Etap tworzenia” i „Część projektu”

Etapy tworzenia zautomatyzowanego systemu sterowania

Etapy tworzenia są określone w GOST 34.601-90. Trzy z nich dotyczą dokumentacji:

• Projekt projektu (ED)
• Projekt techniczny (TP)
• Opracowywanie dokumentacji roboczej (DD)

Projekt wstępny następuje po etapie Specyfikacji Technicznych i służy opracowaniu wstępnych rozwiązań projektowych.

Projekt techniczny opisuje przyszły system ze wszystkich stron. Dokumenty na etapie TP powinny po zapoznaniu się pozostawić pełną jasność co do proponowanych podejść, metod, rozwiązań architektonicznych i technicznych. W następnej fazie będzie już za późno na opisanie podejść i uzasadnienie rozwiązań technicznych, dlatego faza P jest kluczem do pomyślnego zakończenia prac, ponieważ cała różnorodność wymagań specyfikacji technicznych musi znaleźć odzwierciedlenie w dokumentach fazy P W fazie P system może w ogóle nie istnieć.

Dokumentacja robocza zaprojektowane z myślą o pomyślnym wdrożeniu, uruchomieniu i dalszej eksploatacji nowego systemu. Są to dokumenty zawierające bardzo szczegółowe informacje, które opisują byty fizycznie istniejące, w odróżnieniu od fazy P, która opisuje przyszłą świetność.

Części (sekcje) dokumentacji projektowej dotyczące stworzenia zautomatyzowanego systemu sterowania

Obszar tematyczny podzielony jest na „Przepisy”. Na pierwszy rzut oka wydaje się, że taki podział jest zbędny i niepotrzebny. Kiedy jednak zaczniesz pracować z tym zestawem narzędzi w praktyce, osadzona w nim ideologia stopniowo stanie się jasna.

Zautomatyzowany system, zgodnie z definicją kompilatorów GOST, to połączenie sprzętu, oprogramowania i kanałów komunikacyjnych, które przetwarza informacje pochodzące z różnych źródeł zgodnie z określonymi algorytmami i generuje wyniki przetwarzania w postaci dokumentów, struktur danych lub działań kontrolnych. Prymitywny model najprostszego karabinu maszynowego.

Aby w pełni opisać tę „maszynę”, wykonano następujące sekcje (jak na rysunku):

Oprogramowanie, odpowiadając na pytania: jaka logika jest wbudowana w „czarną skrzynkę”? Dlaczego wybrano te konkretne algorytmy, te konkretne formuły i te konkretne współczynniki?

Oprogramowanie matematyczne nie wie nic o procesorach ani bazach danych. To odrębny obszar abstrakcyjny, siedziba „kulistych koni w próżni”. Ale oprogramowanie matematyczne może być bardzo ściśle powiązane z dziedziną, czyli prawdziwym życiem. Przykładowo algorytmy sterujące dla systemów sterowania ruchem muszą zostać zatwierdzone przez Państwową Inspekcję Bezpieczeństwa Ruchu zanim zostaną zatwierdzone przez Klienta. I wtedy rozumiesz, dlaczego umieszczono je w osobnej książce. Bo nikogo w policji drogowej nie interesuje, na jakim systemie operacyjnym będzie działał serwer aplikacji, ale to, jaki znak i ograniczenie prędkości wyskoczy na tablicy w deszczu lub śniegu, jest bardzo interesujące. Ponoszą odpowiedzialność za swoją część i nie zamierzają podpisywać niczego innego. Z drugiej strony, kiedy podpiszą, nie będzie już pytań o techniczną stronę problemu – dlaczego wybrali właśnie te tablice czy sygnalizację świetlną, a nie inne. Mądrość „przodków” objawia się właśnie w takich praktycznych przypadkach.

Wsparcie informacyjne (IS). Kolejny fragment systemu. Tym razem czarna skrzynka naszego systemu staje się przezroczysta i przyglądamy się krążącym w niej informacjom. Wyobraź sobie model ludzkiego układu krążenia, gdy wszystkie inne narządy są niewidoczne. Coś takiego to wsparcie informacyjne. Opisuje skład i drogi przepływu informacji wewnątrz i na zewnątrz, logiczną organizację informacji w systemie, opis podręczników i systemów kodowania (jakie są ważne wiedzą ci, którzy tworzyli programy do produkcji). Główna część opisowa przypada na etap TP, ale pewne „podstawy” wpływają na etap RD, jak np. dokument „Katalog baz danych”. Widać, że wcześniej zawierało dokładnie to, co napisano w tytule. Ale dzisiaj spróbuj stworzyć taki dokument dla złożonego, złożonego systemu, gdy bardzo często system korzysta z zakupionych podsystemów z własnymi tajemniczymi magazynami informacji. Nawet nie twierdzę, że ten dokument nie jest teraz szczególnie potrzebny.

Lub tutaj jest „Oświadczenie dotyczące komputerowych nośników danych”. Jasne jest, że poprzednio zawierał on pewną liczbę bębnów magnetycznych lub rolek folii. Co teraz mam tam wpisać?

Krótko mówiąc, na etapie RD dokumenty wsparcia informacyjnego stanowią raczej szkodliwą podstawę, ponieważ formalnie powinny istnieć, ale nie ma nic specjalnego, czym można by je wypełnić.

Oprogramowanie. Ulubiona przez wszystkich część dokumentacji projektowej. Tak, choćby dlatego, że jest to tylko jeden dokument! I wtedy wszyscy rozumieją, co należy tam zapisać. Ale i tak to powtórzę.

W tym dokumencie musimy poinformować, za pomocą jakiego oprogramowania wykonywane są algorytmy opisane w ML, przetwarzając informacje opisane w przepisach wykonawczych. Oznacza to, że nie ma potrzeby powielania informacji z innych sekcji tutaj. Tutaj podana jest architektura systemu, uzasadnienie wybranych technologii oprogramowania, ich opis (różne rzeczy systemowe: języki programowania, frameworki, systemy operacyjne itp.). Również w tym dokumencie opisujemy organizację narzędzi do przetwarzania informacji (kolejki wiadomości, pamięć masowa, narzędzia do tworzenia kopii zapasowych, rozwiązania w zakresie dostępności, wszelkiego rodzaju pule aplikacji itp.). Norma zawiera szczegółowy opis zawartości tego dokumentu, który zrozumie każdy specjalista.

Wsparcie techniczne (DO). Nie mniej ukochana część dokumentacji projektowej. Różowy obraz przyćmiewa jedynie natłok dokumentów, które należy opracować. Łącznie standard wymaga opracowania 22 dokumentów, z czego 9 znajduje się na etapie TC.

Faktem jest, że norma zawiera opis całego wsparcia technicznego, w tym sprzętu komputerowego i sieci, systemów inżynierskich, a nawet części konstrukcyjnej (jeśli jest wymagana). A tę gospodarkę reguluje ogromna liczba norm i przepisów, koordynowanych w różnych organizacjach, dlatego wygodniej jest podzielić wszystko na części i koordynować (edytować) w częściach. Jednocześnie standard pozwala na łączenie ze sobą niektórych dokumentów, co ma sens, jeśli całość zatwierdza jedna osoba.

Nie zapominaj również, że zbiór standardów jakości zakłada rejestrację i przechowywanie dokumentów technicznych, a nasze „książki” od klienta mogą być dystrybuowane pomiędzy różnymi archiwami, w zależności od przedmiotu opisu. To kolejny argument przemawiający za fragmentaryzacją dokumentacji.

Wsparcie organizacyjne (OO). Po stłumieniu, normalnej dla technika, chęci jak najszybszego pominięcia tej sekcji, wręcz przeciwnie, rozważę to bardziej szczegółowo. Ponieważ, koledzy, ostatnio pojawiły się pewne złe trendy w projektach, które wymagają wyjaśnienia w tej sekcji.

Na etapie TP sekcja zawiera tylko jeden dokument „ Opis struktury organizacyjnej”, w którym musimy powiedzieć klientowi, na co powinien się przygotować w zakresie zmiany struktury organizacyjnej. Nagle trzeba zorganizować nowy dział do obsługi systemu, wprowadzić nowe stanowiska itp.

Na etapie RD pojawiają się inne, ciekawsze dokumenty, które chciałbym osobno rozważyć.

Podręcznik użytkownika. Uważam, że komentarze są niepotrzebne.

Metodologia (technologia) komputerowego wspomagania projektowania. Jeśli zajdzie taka potrzeba, możesz zawrzeć w tym dokumencie opis procesu tworzenia oprogramowania, kontroli wersji, testowania itp. Dzieje się tak jednak w przypadku, gdy Klient w specyfikacji technicznej chce osobiście złożyć oprogramowanie. Jeśli tego nie wymaga (i nie płaci za to), to cała Twoja wewnętrzna kuchnia nie jest jego sprawą i ten dokument nie musi być wykonywany.

Instrukcje technologiczne. W związku z modą na formalizowanie procesów biznesowych, przebiegły klient czasami próbuje upchnąć w tym dokumencie regulaminy operacyjne. Dlatego w żadnym wypadku nie powinieneś tego robić.

Opis procesów biznesowych, opisy ról i stanowisk pracy, regulaminy pracy – to wszystko to ORD, czyli dokumentacja organizacyjno-administracyjna. Który jest produktem projektu doradczego, który, o ile rozumiem, nie został zakupiony od Ciebie. Kupili od Was projekt techniczny i dokumentację techniczną do niego.

Instrukcja technologiczna stanowi warstwę pomiędzy instrukcją obsługi a instrukcją obsługi. RP opisuje szczegółowo Jak musisz wykonać określone czynności w systemie. Instrukcja technologiczna tak mówi Który działania należy wykonać w określonych przypadkach związanych z pracą systemu. Z grubsza mówiąc, instrukcja technologiczna to krótki skrót RP dla określonego stanowiska lub roli. Jeśli klient nie ma utworzonych ról lub chce, abyś sam stworzył role i wymagania stanowiskowe, zawrzyj w dokumencie najbardziej podstawowe role, np.: operator, starszy operator, administrator. Do komentarzy Klienta na temat „ale u nas to nie tak” lub „nie podoba nam się to” należy dołączyć listę ról i opis obowiązków służbowych. Ponieważ procesy biznesowe my nie umieszczamy tego. Jesteśmy tymi procesami biznesowymi zautomatyzować.

O opisanych grabiach napiszę osobno, z kolorowymi przykładami, gdyż nie jest to pierwszy raz, gdy powtarza się to w różnych sektorach „gospodarki narodowej”.

Opis procesu technologicznego przetwarzania danych (w tym teleprzetwarzania). Żałosny relikt epoki jaskini, kiedy istnieli specjalnie wyznaczeni „operatorzy komputerów”, którzy wprowadzali do maszyny karty dziurkowane i pakowali wydruk wyniku w kopercie. Ta instrukcja jest dla nich. Nie potrafię dokładnie powiedzieć, co mam w nim napisać w XXI wieku. Wyjdź sam. Najlepiej po prostu zapomnieć o tym dokumencie.

Rozwiązania systemowe (WSO). Norma przewiduje 17 dokumentów w części OP. Po pierwsze, są to prawie wszystkie dokumenty ze wstępnej fazy projektowania schematu. Po drugie, są to wszelkiego rodzaju szacunki, obliczenia i krótkie opisy zautomatyzowanych funkcji. Czyli informacja dla osób nie z głównej produkcji IT, ale dla personelu pomocniczego - menadżerów, kosztorysantów, specjalistów ds. zakupów, ekonomistów itp.

Po trzecie, OP zawiera megadokument zatytułowany „Nota wyjaśniająca do projektu technicznego”, który w zamierzeniu ma być rodzajem streszczenia wykonawczego, ale w rzeczywistości wielu projektantów umieszcza w nim całą użyteczną treść etapu TP. Takie radykalne podejście może być uzasadnione, a nawet obustronnie korzystne zarówno dla klienta, jak i wykonawcy, ale w określonych przypadkach.

Opcje korzystania z GOST 34

1. Pełne i dokładne przestrzeganie normy. Naturalnie nikt dobrowolnie nie napisze takiej chmury dokumentów. Dlatego też komplet dokumentów przygotowywany jest wyłącznie na pilną prośbę Klienta, którą zabezpieczył on w specyfikacji technicznej i dodatkowo podpiął umową na górze. W takim przypadku należy wszystko potraktować dosłownie i przekazać klientowi fizyczne „książki”, na których będą znajdować się nazwy dokumentów z tabeli 2 GOST 34.201-89, z wyjątkiem zupełnie niepotrzebnych, których listę należy omówić i zabezpieczyć na piśmie. Treść dokumentów musi być również, bez wyobraźni, zgodna z RD 50-34.698-90, aż do nazw sekcji. Aby mózg klienta eksplodował, czasami duży system dzieli się na podsystemy i dla każdego podsystemu wydawana jest osobna dokumentacja projektowa. Wygląda przerażająco i nie podlega normalnej kontroli za pomocą ziemskiego umysłu. Zwłaszcza jeśli chodzi o integrację podsystemów. Co znacznie ułatwia akceptację. Najważniejsze, abyś sam się nie pomylił i aby Twój system nadal działał tak, jak powinien.
2. Po prostu kochamy standardy GOST. Poważne, duże firmy kochają standardy. Ponieważ pomagają ludziom lepiej się rozumieć. Jeśli Twój klient słynie z zamiłowania do porządku i standaryzacji, podczas opracowywania dokumentów staraj się przestrzegać standardowej ideologii GOST, nawet jeśli nie jest to wymagane przez specyfikacje techniczne. Będziesz lepiej zrozumiany i zaakceptowany przez zatwierdzających specjalistów, a sam nie zapomnisz zawrzeć ważnych informacji w dokumentacji, lepiej zobaczysz docelową strukturę dokumentów, dokładniej zaplanujesz pracę nad ich pisaniem, zaoszczędzisz sobie i twoi koledzy dużo nerwów i pieniędzy.
3. Nie przejmujemy się dokumentacją, byle wszystko działało. Znikający wygląd nieodpowiedzialnego klienta. Podobny pogląd na dokumentację wciąż można spotkać wśród małych i biednych klientów, a także w autorytarnych „idiotokracjach” pozostałych po pierestrojce, gdzie szefa otaczają lojalni przyjaciele – dyrektorzy, a wszystkie problemy rozwiązuje się w osobistych rozmowach . W takich warunkach można zupełnie pominąć dokumentację, ale przecież lepiej nie rozwalać celownika i chociaż schematycznie uzupełnić dokumentację treścią. Jeśli nie temu klientowi, to przekaż go (sprzedaj) następnemu.

Wniosek

Ten artykuł dotyczył naszych standardów GOST dotyczących dokumentowania zautomatyzowanych systemów sterowania. GOST są stare, ale jak się okazuje, nadal są bardzo przydatne w gospodarstwie domowym. Poza pewnymi oczywistymi podstawami, struktura dokumentacji charakteryzuje się kompletnością i spójnością, a przestrzeganie normy eliminuje wiele ryzyk projektowych, których istnienia możemy w pierwszej chwili nie być świadomi.

Mam nadzieję, że przedstawiony materiał był dla Ciebie przydatny lub przynajmniej interesujący. Pomimo pozornej nudy dokumentacja to ważna i odpowiedzialna praca, w której dokładność jest równie ważna jak pisanie dobrego kodu. Piszcie dobre dokumenty, koledzy! A w przyszłym tygodniu jadę na dwa wyjazdy służbowe z rzędu, więc nie gwarantuję publikacji nowych materiałów (nie mam kesza, piszę z głowy).

Wstęp

We współczesnym świecie codziennie pojawiają się dziesiątki i setki różnych programów, aplikacji i systemów informatycznych. Można je opracowywać dla sektora rządowego lub komercyjnego, a także dla zwykłych użytkowników. 90% wszystkich użytkowników nie czyta dokumentacji, uważa ją za nudną, żmudną i nieciekawą, a instrukcję obsługi otwiera dopiero wtedy, gdy coś nie działa lub nie da się tego obejść bez instrukcji. Obecnie powszechną praktyką jest projektowanie interfejsu użytkownika w taki sposób, aby był intuicyjny, a użytkownik mógł zrozumieć system bez konieczności czytania długich instrukcji. Jednak podczas pracy z dużymi klientami prawie zawsze konieczne jest przesłanie określonego pakietu dokumentów - instrukcji, instrukcji, rozwiązań projektowych sporządzonych zgodnie z GOST.
Kiedy po raz pierwszy spotykasz się z pisaniem dokumentacji zgodnie z GOST, jesteś oszołomiony i całkowicie zszokowany, ponieważ istnieje „morze” tych GOST i nie jest jasne, jak i co według nich pisać.
W tym artykule omówiono standardy GOST dotyczące pisania dokumentacji i ich główne punkty.

Jakie są standardy GOST?

Najpierw musisz zrozumieć, jakie są standardy GOST. Wszyscy po prostu wiedzą, że GOST to coś, co zostało opracowane w ramach Unii i jest ich po prostu nieskończona liczba. Spieszę zapewnić, że nie ma wielu GOST dla sektora IT i wszystkie, pomimo czasu powstania, nie straciły na znaczeniu.
Przede wszystkim standardy pisania dokumentacji dzielą się na dwa typy:

1. Standardy międzynarodowe (ISO, IEEE Std);
2. Rosyjskie lub radzieckie GOST.

Międzynarodowe standardy
Do opracowania dokumentacji na poziomie międzynarodowym wykorzystywane są standardy międzynarodowe. Z reguły nie są one bezpłatne, ponieważ nie są opracowywane przez organizacje rządowe, ale w przeciwieństwie do naszych zostały opracowane całkiem niedawno. Temat standardów międzynarodowych jest bardzo szeroki, dlatego zostanie omówiony w innym artykule. Poruszono także kilka standardów ściśle związanych z pisaniem dokumentacji.
Lista głównych międzynarodowych standardów pisania dokumentacji:

1. IEEE Std 1063-2001 „IEEE Standard for Software User Documentation” - standard pisania instrukcji obsługi;
2. IEEE Std 1016-1998 „Zalecana praktyka IEEE dotycząca opisów projektów oprogramowania” - standard pisania opisu technicznego programu;
3. ISO/IEC FDIS 18019:2004 „Wytyczne dotyczące projektowania i przygotowywania dokumentacji użytkownika dla oprogramowania aplikacyjnego” to kolejny standard dotyczący pisania instrukcji obsługi. W tym dokumencie znajduje się duża liczba przykładów. Można powiedzieć, że jest to bardziej przewodnik po pisaniu instrukcji obsługi. Będzie to szczególnie przydatne dla początkujących specjalistów;
4. ISO/IEC 26514:2008 „Wymagania dla projektantów i twórców dokumentacji użytkownika” to kolejny standard dla projektantów i twórców dokumentacji użytkownika.

Tak naprawdę istnieje wiele standardów międzynarodowych i każdy kraj ma swój własny, ponieważ ten sam standard nie zawsze będzie odpowiedni zarówno dla firm europejskich, jak i azjatyckich.

Normy rosyjskie
Rosyjskie standardy są opracowywane na poziomie państwowym. Wszystkie są całkowicie bezpłatne i każdy z nich można łatwo znaleźć w Internecie. Do napisania dokumentacji programu stosuje się dwie serie GOST 19 i 34. To właśnie te zostaną omówione dalej.

Jaka jest różnica między serią GOST 19 i 34?

Pierwsze pytanie, które się pojawia, brzmi: jak ogólnie te GOST 19 i 34 różnią się od siebie.
W GOST 19.781-90 „Ujednolicony system dokumentacji programu. Oprogramowanie systemów przetwarzania informacji. Terminy i definicje” wskazane są definicje:

1. Program – dane przeznaczone do sterowania określonymi elementami systemu przetwarzania informacji w celu realizacji określonego algorytmu.
2. Oprogramowanie to zbiór programów systemu przetwarzania informacji oraz dokumentów programowych niezbędnych do działania tych programów.

W GOST 34.003-90 „Technologia informacyjna. Zbiór standardów dla systemów zautomatyzowanych. Zautomatyzowane systemy. Terminy i definicje” wskazano definicję:

1. System zautomatyzowany (AS) - system składający się z personelu i zestawu narzędzi automatyzacji ich działań, wdrażający technologię informatyczną do wykonywania ustalonych funkcji.
   W zależności od rodzaju działalności wyróżnia się na przykład następujące typy AS: zautomatyzowane systemy sterowania (ACS), systemy projektowania wspomaganego komputerowo (CAD), zautomatyzowane systemy badań naukowych (ASRS) i inne.

W zależności od rodzaju kontrolowanego obiektu (procesu) zautomatyzowane systemy sterowania dzielą się np. na: zautomatyzowane systemy sterowania procesami technologicznymi (ACS), zautomatyzowane systemy sterowania dla przedsiębiorstw (ACS) itp.
GOST 34 dokonuje również podziału na rodzaje wsparcia AS:

1. Organizacyjny;
2. Metodyczny;
3. Techniczny;
4. Matematyczny;
5. Oprogramowanie;
6. Informacyjne;
7. Lingwistyczny;
8. Prawny;
9. Ergonomiczny.

W rezultacie System Zautomatyzowany nie jest programem, ale zespołem rodzajów oprogramowania, w tym oprogramowaniem. AS z reguły oferuje rozwiązanie organizacyjne dla konkretnego użytkownika i klienta, a Program można tworzyć i replikować dla dużej liczby użytkowników bez powiązania z jakimkolwiek przedsiębiorstwem.
Dlatego jeśli opracowujesz dokumentację programu, który stworzyłeś dla konkretnego przedsiębiorstwa, Twój GOST wynosi 34. Jeśli piszesz dokumenty dla programu masowego, Twój GOST wynosi 19.

GOST 34

Seria GOST 34 (Normy informatyczne GOST 34.xxx) składa się z:

1. GOST 34.201-89 Rodzaje, kompletność i oznaczenia dokumentów przy tworzeniu zautomatyzowanych systemów - norma ta określa rodzaje, nazwę, kompletność i liczbę dokumentów. Jest to jeden z głównych dokumentów serii GOST 34. Tak naprawdę jest to dokument podstawowy, dlatego początkujący muszą się z nim najpierw zapoznać.
2. GOST 34.320-96 Pojęcia i terminologia dotycząca schematów pojęciowych i baz informacyjnych - norma ta ustanawia podstawowe pojęcia i terminy dotyczące schematów pojęciowych i baz informacyjnych, obejmujące opracowywanie, opis i stosowanie schematów pojęciowych i baz informacyjnych, manipulację informacją, a także opis i realizacja procesu informacyjnego. Norma określa rolę diagramu pojęciowego. Zawarte w nim zapisy mają charakter doradczy i mogą być wykorzystywane do oceny systemów zarządzania bazami danych (SZBD). W tym dokumencie nie opisano konkretnych metod korzystania z narzędzi wspomagających diagramy koncepcyjne. Języki schematu pojęciowego opisane w normie nie powinny być uważane za języki standardowe.
3. GOST 34.321-96 Technologie informacyjne. System standardów baz danych. Model referencyjny zarządzania — ten dokument ustanawia model referencyjny zarządzania danymi.
   Model referencyjny definiuje powszechną terminologię i koncepcje związane z danymi systemów informatycznych. Pojęcia te służą do definiowania usług świadczonych przez systemy zarządzania bazami danych lub systemy słowników danych.
   Model referencyjny nie uwzględnia protokołów zarządzania danymi.
   Zakres modelu referencyjnego obejmuje procesy zajmujące się zarządzaniem danymi trwałymi i ich interakcją z procesami innymi niż wymagania konkretnego systemu informatycznego, a także ogólne usługi zarządzania danymi w zakresie definiowania, przechowywania, wyszukiwania, aktualizacji, wprowadzania, kopiowania , przywracanie i przesyłanie danych.
4. GOST 34.601-90 Systemy zautomatyzowane. Etapy tworzenia - norma określa etapy i etapy tworzenia AS.
5. GOST 34.602-89 Specyfikacje techniczne dotyczące tworzenia zautomatyzowanego systemu (zamiast GOST 24.201-85) - ustala skład, treść, zasady sporządzania dokumentu „Zasady zadań dotyczące tworzenia (rozwoju lub modernizacji) systemu. ”
   Dokument ten jest jednym z często używanych dokumentów z serii GOST 34. Opracowując specyfikacje techniczne tego GOST, należy pamiętać o innych normach, nawet jeśli dokument ten nie zawiera odniesień do tych norm.
6. GOST 34.603-92 Technologia informacyjna. Rodzaje testów systemów zautomatyzowanych - norma określa rodzaje testów AS (testy autonomiczne, złożone, akceptacyjne i działanie próbne) oraz ogólne wymagania dotyczące ich realizacji.
7. RD 50-34.698-90 Systemy zautomatyzowane. Wymagania dotyczące treści dokumentów są jednym z najważniejszych dokumentów GOST 34, ponieważ opisuje treść prawie wszystkich dokumentów, a także opis każdego akapitu dokumentu.
8. GOST R ISO/IEC 8824-3-2002 Technologia informacyjna. Abstrakcyjna notacja składni, wersja pierwsza — ten standard jest częścią abstrakcyjnej notacji składni, wersja 1 (ASN.1) i ustanawia notację dla specyfikacji ograniczeń zdefiniowanych przez użytkownika i ograniczeń tabelarycznych.
9. GOST R ISO/IEC 10746-3-2001 Zarządzanie danymi i otwarte przetwarzanie rozproszone.
   W tym standardzie:
   • określono sposób specyfikacji otwartych systemów przetwarzania rozproszonego (ODP) przy użyciu koncepcji wprowadzonych w GOST R ISO/IEC 10746-2;
   • Zidentyfikowano cechy, według których systemy należą do systemów OPO.

   Norma ustanawia ramy koordynacji opracowywania standardów dla systemów ODP.

10. GOST R ISO/IEC 15271-02 Procesy cyklu życia oprogramowania - ten GOST jest moim zdaniem bardziej potrzebny analitykom podczas projektowania i modelowania AS.
    Z mojego punktu widzenia dokument ten jest przydatny do celów czysto edukacyjnych.
11. GOST R ISO/IEC 15910-2002 Proces tworzenia dokumentacji użytkownika dla narzędzia programowego - definiuje minimalny wymagany proces tworzenia dokumentacji użytkownika wszystkich typów dla narzędzia programowego posiadającego interfejs użytkownika. Do typów tych zalicza się dokumentację drukowaną (na przykład podręczniki użytkownika i karty skróconych informacji), dokumentację online, teksty pomocy i systemy dokumentacji online.

Zatem na podstawie wszystkiego, co napisano powyżej, jasne jest, że główne dokumenty w GOST 34 to 3: GOST 34.201-89, RD 50-34.698-90 i GOST 34.602-89.
Opracowując pakiet dokumentacji, najpierw należy otworzyć GOST 34.201-89 i wybrać etap tworzenia: projekt projektu, projekt techniczny i dokumentacja robocza. Następnie należy wybrać dokumenty do opracowania odpowiadające etapowi tworzenia.

Lista dokumentów 34 GOST

Scena kreacja	Tytuł dokumentu	Kod	Część projekt	Prinad łóżko Do projekt ale-oszacuj Noaha Doku policjant cje	Prinad łóżko Do eksploatacja tacja nie, wstawaj kumen cje	Dodatkowe instrukcje
PE	Arkusz projektu wstępnego	EP*	LUB	—	—	—
	Notatka wyjaśniająca Do wstępnego projektu	P1	LUB	—	—	—
EP, TP	Schemat organizacyjny	WSPÓŁ	LUB	—	—	Dopuszczalne jest umieszczenie w dokumencie P3 lub PV
	Schemat strukturalny kompleksu środki techniczne	C1*	TO	X	—
	Schemat struktury funkcjonalnej	C2*	LUB	—	—	Przy opracowywaniu dokumentów CO, C1, C2, C3 na etapie ES dopuszcza się umieszczenie ich w dokumencie P1
	specjalistyczne (nowe) środki techniczne	O 9	TO	X	—	Podczas opracowywania na etapie technicznym wolno zawierać udokumentować P2
	Schemat automatyzacji	C3*	TO	X	—	—
	Specyfikacje techniczne dotyczące rozwoju specjalistyczne (nowe) środki techniczne	—	TO	—	—	Projekt nie zawiera
TP	Zadania rozwojowe sanitarne i inne sekcje związane z projektem z utworzeniem systemu	—	TO	X	—	Projekt nie zawiera
	Karta projektu technicznego	TP*	LUB	—	—	—
	Lista zakupionych przedmiotów	wiceprezes*	LUB	—	—	—
	Lista sygnałów wejściowych i dane	W 1	I O	—	—	—
	Lista sygnałów wyjściowych (dokumenty)	O 2	I O	—	—	—
	Lista zadań programistycznych budowlane, elektryczne, sanitarne i inne sekcje związane z projektem z utworzeniem systemu	O 3	TO	X	—	Dopuszczalne jest umieszczenie w dokumencie P2
	Notatka wyjaśniająca do projektu technicznego	P2	LUB	—	—	Zawiera plan wydarzenia na temat przygotowania obiektu do wprowadzenia systemy do działania
	Opis automatu Funkcje	P3	LUB	—	—	—
	Opis ustawienia zadania (zestaw zadań)	P4	LUB	—	—	Dozwolone włączenie do dokumentów P2 lub P3
	Opis informacji zapewnienie systemu	P5	I O	—	—	—
	Opis organizacji baza informacyjna	P6	I O	—	—	—
TP	Opis systemów klasyfikacji i kodowanie	P7	I O	—	—	—
	Opis tablicy Informacja	P8	I O	—	—	—
	Opis kompleksu środki techniczne	P9	TO	—	—	Do zadania można dołączyć w dokumencie 46 zgodnie z GOST 19.101
	Opis oprogramowania zaopatrzenie	ROCZNIE	PRZEZ	—	—	—
	Opis algorytmu (procedura projektowa)	PB	MO	—	—	Dopuszczalne jest umieszczanie w dokumentach P2, P3 lub P4
	Opis organizacyjny Struktury	PV	OO	—	—	—
	Plan zagospodarowania	C8	TO	X	—	Dopuszczalne jest umieszczenie w dokumencie P9
	Lista wyposażenia i materiały	—	TO	X	—	—
	Lokalne obliczenia szacunkowe	B2	LUB	X	—	—
TP, RD	Ocena projektu niezawodność systemu	B1	LUB	—	—	—
	Rysunek formularza dokumentu (klatka wideo)	C9	I O	—	X	Na etapie TP jest to dozwolone uwzględnić w dokumentach P4 lub P5
R & D	Lista posiadaczy oryginały	DP*	LUB	—	—	—
	Arkusz operacyjny dokumenty	zaburzenia erekcji*	LUB	—	X	—
	Specyfikacja sprzętu	O 4	TO	X	—	—
	Lista wymagań w materiałach	O 5	TO	X	—	—
	Inwentarz nośników maszynowych Informacja	maszyna wirtualna*	I O	—	X	—
	Tablica wejściowa	NA 6	I O	—	X	—
R & D	Katalog bazy danych	W 7	I O	—	X	—
	Skład danych wyjściowych (wiadomości)	O 8	I O	—	X	—
	Szacunki lokalne	B3	LUB	X	—	—
	Metodologia (technologia) zautomatyzowane projekt	I1	OO	—	X	—
	Instrukcje technologiczne	ORAZ 2	OO	—	X	—
	Podręcznik użytkownika	I3	OO	—	X	—
	Instrukcje formowania i utrzymanie bazy danych (zbiór danych)	I4	I O	—	X	—
	Instrukcja obsługi KTS	TJ	TO	—	X	—
	Schemat okablowania zewnętrznego	C4*	TO	X	—	Dopuszczone do wykonania w w formie tabel
	Diagram połączeń wpisy zewnętrzne	C5*	TO	X	—	To samo
	Tabela połączeń i połączeń	C6	TO	X	—	—
	Schemat podziału systemu (strukturalny)	E1*	TO	—	—	—
	Rysunek ogólny	W*	TO	X	—	—
	Rysunek instalacji urządzeń technicznych	SA	TO	X	—	—
	Schemat	SB	TO	X	—	—
	Schemat strukturalny kompleksu środki techniczne	C1*	TO	X	—	—
	Plan rozmieszczenia sprzętu i okablowania	C7	TO	X	—	—
	Opis technologiczny proces przetwarzania dane (m.in teleprzetwarzanie)	PG	OO	—	X	—
	Ogólny opis systemu	PD	LUB	—	X	—
	Program i metodologia testów (komponenty, systemy automatyki, podsystemy, systemy)	PO POŁUDNIU*	LUB	—	—	—
	Formularz	FO*	LUB	—	X	—
	Paszport	PS*	LUB	—	X	—
*Dokumenty, których kod jest ustawiony zgodnie z wymaganiami norm ESKD

Uwaga do tabeli:

1. W tabeli zastosowano następujące oznaczenia:
   • EP - projekt wstępny;
   • TP - projekt techniczny;
   • RD - dokumentacja robocza;
   • LUB - rozwiązania ogólnosystemowe;
   • OO - decyzje dotyczące wsparcia organizacyjnego;
   • TO - rozwiązania w zakresie wsparcia technicznego;
   • IO - rozwiązania wsparcia informacyjnego;
   • Oprogramowanie – rozwiązania programowe;
   • MO - rozwiązania programowe.
2. Znak X oznacza, że ​​należy on do szacunków projektowych lub dokumentacji eksploatacyjnej.
3. Nazewnictwo dokumentów o tej samej nazwie ustalane jest w zależności od decyzji projektowych podjętych podczas tworzenia systemu.

Po ustaleniu listy dokumentów należy w RD 50-34.698-90 znaleźć wybrane dokumenty i opracować je ściśle według określonych punktów. Wszystkie wskazane punkty treści muszą znajdować się w dokumencie.
Jeśli opracowywane są Specyfikacje techniczne, należy natychmiast otworzyć GOST 34.602-89 i opracować specyfikacje techniczne ściśle zgodnie z punktami.

GOST 19

Seria GOST 19 (GOST 19.xxx Unified System of Program Documentation (USPD)) składa się z:

1. 1. GOST 19.001-77 Przepisy ogólne - dokument zbyt ogólny, nie ma praktycznego zastosowania. Dlatego możesz to pominąć.
   2. GOST 19781-90 Terminy i definicje - dobra lista definicji z zakresu oprogramowania dla systemów przetwarzania informacji. Nie zawiera niczego poza definicjami.
   3. GOST 19.101-77 Rodzaje programów i dokumentów programowych - jeden z głównych dokumentów 19 GOST. Od tego należy rozpocząć pracę z GOST 19, ponieważ zawiera on pełną listę i oznaczenia dokumentów GOST.

Lista dokumentów 19 GOST

Kod	Typ dokumentu	Etapy rozwoju
		Szkicowy projekt	Techniczny projekt	Projekt roboczy
				część	złożony
—	Specyfikacja	—	—
05	Lista oryginalnych posiadaczy	—	—	—
12	Tekst programu	—	—
13	Opis programu	—	—
20	Lista dokumentów operacyjnych	—	—
30	Formularz	—	—
31	Opis aplikacji	—	—
32	Przewodnik programisty systemu	—	—
33	Przewodnik programisty	—	—
34	Instrukcja obsługi	—	—
35	Opis języka	—	—
46	Podręcznik techniczny praca	—	—
51	Program i metodologia testów	—	—
81	Notatka wyjaśniająca			—	—
90-99	Inne dokumenty

Legenda:
— dokument jest obowiązkowy;
— dokument jest obowiązkowy w przypadku komponentów mających niezależne zastosowanie;
— konieczność sporządzenia dokumentu ustalana jest na etapie opracowywania i zatwierdzania specyfikacji technicznych;
- - dokument nie jest sporządzony.

1. GOST 19.102-77 Etapy rozwoju - zawiera opis etapów rozwoju. Przydatne do celów edukacyjnych. Moim zdaniem nie ma to zbyt wielu praktycznych zalet.
2. GOST 19.103-77 Oznaczenia programów i dokumentów programowych - zawiera opis nadawania numeru (kodu) dokumentowi. Nawet po przeczytaniu tego GOST pozostaje wiele pytań dotyczących przypisania tego samego numeru do dokumentu.
3. GOST 19.104-78 Główne napisy - określa formy, rozmiary, lokalizację i procedurę wypełniania głównych napisów arkusza homologacji i strony tytułowej w dokumentach programowych przewidzianych w standardach ESPD, niezależnie od metod ich realizacji. Ponieważ dokumenty 19 GOST są sporządzone w ramkach, dokument ten jest bardzo ważny.
4. GOST 19.105-78 Ogólne wymagania dotyczące dokumentów programowych - ustanawia ogólne wymagania dotyczące przygotowywania dokumentów programowych. Wymagania są zbyt ogólne. Z reguły ten GOST prawie nie jest używany do opracowywania dokumentu, ponieważ wystarczy specjalny GOST dla dokumentu, ale dla ogólnej wiedzy nadal lepiej jest raz zajrzeć do tego GOST.
5. GOST 19.106-78 Wymagania dotyczące dokumentów programowych wykonanych w formie drukowanej - zawiera wymagania dotyczące wykonania wszystkich dokumentów 19 GOST.
6. GOST 19.201-78 Specyfikacje techniczne, wymagania dotyczące treści i projektu - ustanawia procedurę konstruowania i przygotowywania specyfikacji technicznych dotyczących rozwoju programu lub oprogramowania.

   Klauzule specyfikacji technicznych 34 GOST i 19 GOST są różne.

7. GOST 19.601-78 Ogólne zasady powielania, księgowania i przechowywania - ogólne zasady powielania, obiegu, księgowania i przechowywania dokumentów programowych. GOST opisuje w kilku punktach, jak zapewnić, że dokumenty nie zostaną utracone.
8. GOST 19.602-78 Zasady powielania, rozliczania i przechowywania dokumentów programowych, wykonania drukowania. Metoda - dodatek do GOST 19.601-78.
9. GOST 19.603-78 Ogólne zasady dokonywania zmian - określa ogólne zasady dokonywania zmian w dokumentach programowych. W istocie opisuje długi biurokratyczny algorytm wprowadzania zmian w dokumentach.
10. GOST 19.604-78 Zasady dokonywania zmian w dokumentach programowych sporządzonych drukiem - opisuje procedurę pracy i wypełniania Arkusza rejestracji zmian.

Lista wyspecjalizowanych GOST, czyli każdy z nich opisuje treść i wymagania dotyczące konkretnego dokumentu:

1. Specyfikacja GOST 19.202-78. Wymagania dotyczące treści i projektu;
2. GOST 19.301-79 Program i metodologia testów. Wymagania dotyczące treści i projektu;
3. GOST 19.401-78 Tekst programu. Wymagania dotyczące treści i projektu;
4. GOST 19.402-78 Opis programu;
5. GOST 19.403-79 Lista oryginalnych posiadaczy;
6. GOST 19.404-79 Nota wyjaśniająca. Wymagania dotyczące treści i projektu;
7. Formularz GOST 19.501-78. Wymagania dotyczące treści i projektu;
8. GOST 19.502-78 Opis zastosowania. Wymagania dotyczące treści i projektu;
9. GOST 19.503-79 Przewodnik programisty systemu. Wymagania dotyczące treści i projektu;
10. Przewodnik programisty GOST 19.504-79. Wymagania dotyczące treści i projektu;
11. GOST 19.505-79 Instrukcja obsługi. Wymagania dotyczące treści i projektu;
12. GOST 19.506-79 Opis języka. Wymagania dotyczące treści i projektu;
13. GOST 19.507-79 Zestawienie dokumentów operacyjnych;
14. GOST 19.508-79 Instrukcja konserwacji. Wymagania dotyczące treści i projektu.

Procedura pracy z 19 GOST:

1. W GOST 19.101-77 wybierz dokument i jego kod zgodnie z etapem rozwoju.
2. Zgodnie z GOST 19.103-77 przypisz numer do dokumentu.
3. Następnie zgodnie z GOST 19.104-78 i 19.106-78 sporządź dokument.
4. Ze specjalistycznej listy GOST należy wybrać tę, która odpowiada opracowywanemu dokumentowi.

Wniosek

GOST nie jest straszny i łatwy! Najważniejsze jest, aby zrozumieć, co należy napisać i jaki GOST jest do tego używany. Nasze główne GOST 19 i 34 dotyczące pisania dokumentacji są bardzo stare, ale nadal aktualne. Napisanie dokumentacji zgodnie ze standardem eliminuje wiele problemów pomiędzy wykonawcą a klientem. W rezultacie oszczędza czas i pieniądze.

Data wprowadzenia 01.01.92

Niniejsza norma dotyczy systemów zautomatyzowanych (AS) stosowanych w różnego rodzaju działalności (badania, projektowanie, zarządzanie itp.), w tym ich kombinacji tworzonych w organizacjach, stowarzyszeniach i przedsiębiorstwach (zwanych dalej organizacjami).

Norma określa etapy i etapy tworzenia AS. Załącznik nr 1 przedstawia treść pracy na każdym etapie.

1. Postanowienia ogólne

2. Etapy i etapy tworzenia AS

Załącznik 1 (w celach informacyjnych)

Dodatek 2 (odniesienie)

1. POSTANOWIENIA OGÓLNE

1.1. to zespół prac uporządkowanych w czasie, wzajemnie powiązanych, połączonych w etapy i fazy, których realizacja jest konieczna i wystarczająca do stworzenia zautomatyzowanego systemu spełniającego określone wymagania.

1.2. Wyróżniono etapy i fazy tworzenia AS jako części procesu tworzenia ze względu na racjonalne planowanie i organizację pracy kończącej się danym rezultatem.

1.3. Prace nad rozwojem AS prowadzone są według etapów i kroków zastosowanych do stworzenia AS.

1.4. Skład i zasady wykonywania prac na etapach i etapach określonych w niniejszej normie są określone w odpowiedniej dokumentacji organizacji zajmujących się tworzeniem poszczególnych typów elektrowni jądrowych.

Wykaz organizacji zaangażowanych w tworzenie elektrowni jądrowych znajduje się w załączniku 2.

2. ETAPY I ETAPY TWORZENIA AS

2.1. Etapy i etapy tworzenia AS są ogólnie pokazane w tabeli.

Gradacja	Etapy pracy
1. Formowanie wymagań dla prelegentów	1.1. Kontrola obiektu i uzasadnienie konieczności utworzenia elektrowni jądrowej
	1.2. Tworzenie wymagań użytkowników dotyczących głośników
	1.3. Przygotowanie raportu z wykonanej pracy oraz wniosku o opracowanie AS (specyfikacje taktyczno-techniczne)
2. Opracowanie koncepcji AC	2.1. Studiowanie obiektu
	2.2. Przeprowadzenie niezbędnych prac badawczych
	2.3. Opracowanie opcji koncepcji AC i wybór opcji koncepcji AC spełniającej wymagania użytkownika
	2.4. Sporządzenie protokołu z wykonanej pracy
3. Zakres obowiązków	3.1. Opracowywanie i zatwierdzanie specyfikacji technicznych budowy elektrowni jądrowych
4. Projekt projektu	4.1. Opracowanie wstępnych rozwiązań projektowych systemu i jego części
	4.2. Opracowanie dokumentacji systemu głośnikowego i jego części
5. Projekt techniczny	5.1. Opracowywanie rozwiązań konstrukcyjnych systemu i jego części
	5.2. Opracowanie dokumentacji systemu głośnikowego i jego części
	5.3. Opracowanie i wykonanie dokumentacji na dostawę produktów do realizacji elektrowni jądrowej i (lub) wymagań technicznych (specyfikacje techniczne) na ich rozwój
	5.4. Opracowanie zadań projektowych w sąsiadujących częściach projektu obiektu automatyki
6. Dokumentacja robocza	6.1. Opracowanie dokumentacji roboczej systemu i jego części
	6.2. Opracowywanie lub adaptacja programów
7. Wejście i działanie	7.1. Przygotowanie obiektu automatyki do uruchomienia EJ
	7.2. Szkolenie personelu
	7.3. Kompletny zestaw głośników z dostarczonymi produktami (oprogramowanie i sprzęt, systemy oprogramowania i sprzętu, produkty informacyjne)
	7.4. Prace budowlano-montażowe
	7,5. Prace uruchomieniowe
	7.6. Przeprowadzenie badań wstępnych
	7.7. Przeprowadzenie próbnej operacji
	7.8. Przeprowadzanie testów akceptacyjnych
8. Wsparcie AC	8.1. Wykonywanie prac zgodnie ze zobowiązaniami gwarancyjnymi
	8.2. Serwis pogwarancyjny

2.2. Etapy i kamienie milowe realizowane przez organizacje uczestniczące w tworzeniu elektrowni jądrowych są określone w umowach i specyfikacjach technicznych opartych na tej normie.

Istnieje możliwość wyłączenia etapu „Projektu Szkicowego” oraz poszczególnych etapów prac na wszystkich etapach, aby połączyć etapy „Projekt techniczny” i „Dokumentacja robocza” w jeden etap „Projekt techniczny szczegółowy”. W zależności od specyfiki tworzonego AS i warunków ich tworzenia, dopuszcza się realizację poszczególnych etapów prac przed zakończeniem poprzednich etapów, równoległą realizację etapów prac lub włączenie nowych etapów prac.

ZAŁĄCZNIK 1.W celach informacyjnych

1. Na etapie 1.1 „Przegląd obiektu i uzasadnienie potrzeby utworzenia elektrowni jądrowej” w ogólnym przypadku przeprowadza się:

• gromadzenie danych o obiekcie automatyki i rodzajach prowadzonych czynności;
• ocena jakości funkcjonowania obiektu i rodzaju prowadzonej działalności, identyfikacja problemów możliwych do rozwiązania za pomocą narzędzi automatyzacji;
• ocena (techniczna, ekonomiczna, społeczna itp.) możliwości utworzenia elektrowni jądrowej.

2. Na etapie 1.2 „Formowanie wymagań użytkownika dla głośników” przeprowadza się:

• przygotowanie danych wstępnych do formułowania wymagań dla zautomatyzowanego systemu (charakterystyka obiektu automatyki, opis wymagań dla systemu, ograniczenia akceptowalnych kosztów rozwoju, uruchomienia i eksploatacji, oczekiwany efekt od systemu, warunki utworzenia i działanie systemu);
• formułowanie i realizacja wymagań użytkownika dotyczących głośników.

3. Na etapie 1.3 „Wypełnienie raportu z wykonanych prac i wniosku o opracowanie AS (specyfikacje taktyczno-techniczne)”, raport z wykonanych prac na tym etapie oraz wniosek o opracowanie AS (specyfikacje taktyczne) i specyfikacje techniczne) lub inny dokument go zastępujący są uzupełnione o podobnej treści.

4. Na etapach 2.1 „Badanie obiektu” i 2.2 „Przeprowadzenie niezbędnych prac badawczych” organizacja rozwojowa przeprowadza szczegółowe badanie obiektu automatyki oraz niezbędne prace badawcze (B+R) związane ze znalezieniem sposobów i oceną możliwości realizuje wymagania użytkowników, sporządza i zatwierdza raporty z badań.

5. Na etapie 2.3 „Opracowanie wariantów koncepcji AS i wybór wariantu koncepcji AS spełniającego wymagania użytkownika”, w ogólnym przypadku, przedstawiane są alternatywne warianty tworzonej koncepcji AS oraz plany ich wdrożenia rozwinięty; ocena zasobów niezbędnych do ich wdrożenia i utrzymania; ocena zalet i wad każdej opcji; porównanie wymagań użytkownika i charakterystyki proponowanego systemu oraz wybór optymalnej opcji; określenie trybu oceny jakości i warunków akceptacji systemu; ocena efektów uzyskanych z systemu.

6. Na etapie 2.4 „Przygotuj raport z wykonanych prac” przygotuj i sporządź raport zawierający opis prac wykonanych na etapie, opis i uzasadnienie proponowanej wersji koncepcji systemu.

7. Na etapie 3.1 „Opracowanie i zatwierdzenie specyfikacji technicznych budowy elektrowni jądrowej” opracowywanie, wykonanie, koordynacja i zatwierdzanie specyfikacji technicznych elektrowni jądrowej oraz, w razie potrzeby, specyfikacji technicznych części elektrowni jądrowej elektrownia są realizowane.

8. Na etapie 4.1 „Opracowanie wstępnych rozwiązań projektowych systemu i jego części” określa się: funkcje AS; funkcje podsystemów, ich cele i skutki; skład zespołów zadaniowych i poszczególnych zadań; koncepcje bazy informacyjnej, jej powiększona struktura; funkcje systemu zarządzania bazami danych; skład systemu obliczeniowego; funkcje i parametry podstawowego oprogramowania.

9. Na etapie 5.1 „Opracowanie rozwiązań projektowych systemu i jego części” zapewniają opracowanie ogólnych rozwiązań systemu i jego części, struktury funkcjonalno-algorytmicznej systemu, funkcji kadrowych i struktury organizacyjnej, struktura środków technicznych, algorytmy rozwiązywania problemów i używane języki, organizacja i utrzymanie bazy informacyjnej, system klasyfikacji i kodowania informacji, oprogramowanie.

10. Na etapach 4.2 i 5.2 „Opracowanie dokumentacji elektrowni jądrowej i jej części” następuje opracowanie, wykonanie, koordynacja i zatwierdzenie dokumentacji w zakresie niezbędnym do opisania pełnego zestawu podjętych decyzji projektowych i wystarczającym do dalszego realizacja prac nad utworzeniem EJ. Rodzaje dokumentów - zgodnie z GOST 34.201.

11. Na etapie 5.3 „Opracowanie i wykonanie dokumentacji na dostawę produktów do budowy elektrowni jądrowych i (lub) wymagań technicznych (specyfikacje techniczne) do ich rozwoju” realizowane jest przygotowanie i wykonanie dokumentacji na dostawę produktów do budowy elektrowni jądrowych ; określanie wymagań technicznych i opracowywanie specyfikacji technicznych dla rozwoju produktów, które nie są produkowane masowo.

12. Na etapie 5.4 „Opracowanie zadań projektowych w sąsiadujących częściach projektu automatyki” opracowują, formalizują, koordynują i zatwierdzają zadania projektowe w sąsiednich częściach projektu obiektu automatyki w celu wykonania prac konstrukcyjnych, elektrycznych, sanitarnych i innych prac przygotowawczych związanych do stworzenia AC.

13. Na etapie 6.1 „Opracowanie dokumentacji roboczej instalacji i jej części” opracowywana jest dokumentacja robocza zawierająca wszystkie niezbędne i wystarczające informacje dla zapewnienia realizacji prac nad uruchomieniem EJ i jej eksploatacji, a także utrzymania poziom cech eksploatacyjnych (jakości) systemu zgodnie z przyjętymi decyzjami projektowymi, jego wykonanie, koordynacja i zatwierdzenie. Rodzaje dokumentów - zgodnie z GOST 34.201.

14. Na etapie 6.2 „Rozwój lub adaptacja programów” opracowywane są programy i oprogramowanie systemowe, selekcja, adaptacja i (lub) łączenie zakupionego oprogramowania oraz opracowywanie dokumentacji programu zgodnie z GOST 19.101.

15. Na etapie 7.1 „Przygotowanie obiektu automatyki do uruchomienia zakładu” prowadzone są prace nad organizacyjnym przygotowaniem obiektu automatyki do oddania zakładu do eksploatacji, obejmujące: wdrożenie rozwiązań projektowych struktury organizacyjnej zakładu zakład; zaopatrywanie działów placówki zarządzającej w materiały instruktażowe i metodyczne; implementacja klasyfikatorów informacji.

16. Na etapie 7.2 „Szkolenie personelu” przeprowadzane jest szkolenie personelu i sprawdzanie jego zdolności do zapewnienia funkcjonowania zakładu.

17. Na etapie „Kompletowania głośników w dostarczone produkty” zapewniają odbiór seryjnych i jednostkowych komponentów, materiałów i produktów instalacyjnych. Przeprowadzana jest kontrola jakości przychodzącej przesyłki.

18. Na etapie 7.4 „Prace budowlano-montażowe” realizowane są: prace przy budowie specjalistycznych budynków (lokalów) przeznaczonych dla urządzeń technicznych i personelu EJ; budowa kanałów kablowych; wykonywanie prac związanych z instalacją urządzeń technicznych i linii komunikacyjnych; testowanie zainstalowanych urządzeń technicznych; dostawa wyposażenia technicznego do uruchomienia.

19. Na etapie 7.5 „Rozruch” dokonują autonomicznej regulacji sprzętu i oprogramowania, ładują informacje do bazy danych i sprawdzają system pod kątem jego utrzymania; kompleksowa konfiguracja wszystkich narzędzi systemowych.

20. Na etapie 7.6 „Przeprowadzenie badań wstępnych” przeprowadza się:

• badanie głośników pod kątem funkcjonalności i zgodności ze specyfikacjami technicznymi zgodnie z programem i metodologią testów wstępnych;
• rozwiązywanie problemów i wprowadzanie zmian w dokumentacji EJ, w tym dokumentacji eksploatacyjnej zgodnie z protokołem z badań;
• sporządzenie protokołu przyjęcia EJ do eksploatacji próbnej.

21. Na etapie 7.7 „Prowadzenie eksploatacji próbnej” prowadzona jest eksploatacja próbna EJ; analiza wyników próbnej eksploatacji EJ; modyfikacja (w razie potrzeby) oprogramowania AS; dodatkowe dostosowanie (w razie potrzeby) wyposażenia technicznego EJ; wykonanie zaświadczenia o zakończeniu eksploatacji próbnej.

22. Na etapie 7.8 „Przeprowadzenie testów odbiorczych” przeprowadza się:

• badania na zgodność ze specyfikacjami technicznymi zgodnie z programem i metodyką badań akceptacyjnych;
• analiza wyników testów AS i eliminacja braków zidentyfikowanych w trakcie testów;
• wykonanie aktu przyjęcia EJ do pracy ciągłej.

23. Na etapie 8.1 „Wykonywanie prac zgodnie z obowiązkami gwarancyjnymi” prowadzone są prace mające na celu usunięcie usterek stwierdzonych podczas eksploatacji EJ w ustalonych okresach gwarancyjnych oraz dokonanie niezbędnych zmian w dokumentacji EJ.

24. Na etapie 8.2 „Serwis pogwarancyjny” prowadzone są prace w zakresie:

• analiza funkcjonowania systemu;
• identyfikację odchyleń rzeczywistych charakterystyk eksploatacyjnych elektrowni jądrowej od wartości projektowych;
• ustalenie przyczyn tych odchyleń;
• eliminacja zidentyfikowanych braków i zapewnienie stabilności charakterystyki pracy EJ;
• dokonanie niezbędnych zmian w dokumentacji głośników.

ZAŁĄCZNIK 2. Odniesienie

WYKAZ ORGANIZACJI UCZESTNICZĄCYCH W TWORZENIU AU

1. Organizacja klienta (użytkownik), dla której zostanie utworzona elektrownia jądrowa i która zapewnia finansowanie, odbiór prac i eksploatację elektrowni jądrowej, a także realizację poszczególnych prac nad utworzeniem elektrowni jądrowej.

2. Organizacja rozwojowa, która prowadzi prace nad stworzeniem AS, zapewniając klientowi zestaw usług naukowo-technicznych na różnych etapach i etapach tworzenia, a także opracowując i dostarczając różne oprogramowanie i sprzęt dla AS.

3. Organizacja dostawców, która produkuje i dostarcza oprogramowanie i sprzęt na zamówienie programisty lub klienta.

4. Organizacja-generalny projektant obiektu automatyki.

5. Organizacje projektowe poszczególnych części projektu obiektu automatyki do wykonania prac konstrukcyjnych, elektrycznych, sanitarnych i innych przygotowawczych związanych z utworzeniem elektrowni jądrowej.

6. Budowa, instalacja, uruchomienie i inne organizacje.

Uwagi:

1. W zależności od warunków utworzenia elektrowni jądrowej możliwe są różne kombinacje funkcji klienta, dewelopera, dostawcy i innych organizacji zaangażowanych w utworzenie elektrowni jądrowej.

2. Na podstawie niniejszego standardu określa się etapy i fazy prac, jakie wykonują w celu utworzenia AS.

DANE INFORMACYJNE

1. OPRACOWANE I WPROWADZONE przez Państwowy Komitet ZSRR ds. Zarządzania Jakością Produktów i Standardów

DEWELOPERS

Yu.H. Vermishev, doktor inżynierii. nauki; Ya.G. Vilenchik; W I. Voropaev, doktor inżynierii. nauki; L.M. Seidenberg, dr. technologia nauki; Yu.B. Irz, dr. technologia nauki; V.D. Kostiukow, dr. technologia nauki; MAMA. Labutin, dyr. technologia nauki; N.P. Leskowska; JEST. Mitiajew; V.F. Popow (lider tematu); S.V. Garszina; sztuczna inteligencja Głuchota; POŁUDNIE. Żukow, dr. nauki; Z P. Zadubowska; V.G. Iwanow; Yu.I. Karavanov, dr. nauki; AA Kłoczkow; V.Yu. Korolow; W I. Makhnach, dr. technologia nauki; S.B. Michałow, doktor inżynierii. nauki; V.N. Petrikiewicz; VA Rachmanow, dr. ekonomia. nauki; AA Ratkowicz; R.S. Sedegov, doktor ekonomii. nauki; N.V. Stepanczikowa; SM. Surowiec; AV Flegentow; LO Chwilewski, dr. technologia nauki; VC. Chistov, dr. ekonomia. nauki

2. ZATWIERDZONE I WPROWADZONE W ŻYCIE Uchwałą Państwowego Komitetu ZSRR ds. Zarządzania Jakością Produktów i Norm z dnia 29 grudnia 1990 r. Nr 3469

M. Ostrogorski, 2008

Aby skutecznie zastosować GOST 34, należy zrozumieć, jak z punktu widzenia tego zestawu standardów zbudowany jest zautomatyzowany system. W przeciwnym razie w gościu nie zobaczymy nic poza długą listą dokumentów o tajemniczych nazwach, a wymagania co do ich treści po raz kolejny przekonają nas, że w wielu mądrościach kryje się wiele smutku. Dlatego zanim zaczniemy omawiać same dokumenty, musimy zrozumieć, co jest przedmiotem dokumentacji.

System zautomatyzowany, jego funkcje i zadania

Definicja systemu zautomatyzowanego

GOST 34.003-90 zawiera następującą definicję systemu zautomatyzowanego: system składający się z personelu i zestawu narzędzi automatyzacji ich działań, wdrażający technologię informatyczną do wykonywania ustalonych funkcji. Co właściwie oznacza ta definicja? Można to zrozumieć jedynie czytając inne definicje tego standardu i porównując je ze sobą. Co teraz zrobimy?

Cele aktywności

Zautomatyzowany system może istnieć tylko wtedy, gdy personel jest zaangażowany w określoną czynność. Zazwyczaj mówimy o działaniach, których rezultaty komuś się przydadzą, niezależnie od zastosowanych narzędzi. Na przykład idę do kasy teatru po bilet i jestem całkiem szczęśliwy, jeśli kasjer wypisuje mi to długopisem na formularzu, o ile wpuszczą mnie do teatru za jego pomocą. Kasjer w zasadzie nie dba również o to, jak dokładnie bilet jest wykonany. Spodoba jej się każda metoda, pod warunkiem, że nie będzie ona zbyt pracochłonna i zapewni jej możliwość sprzedania mi biletu. Innymi słowy, ona i ja mamy wspólny cel. GOST 34.003-90 używa tego terminu do jego oznaczenia cel działalności. Za każdym razem, gdy kolejny widz odchodzi od okna z biletem w ręku, a teatr staje się nieco bogatszy, ten cel działania zostaje osiągnięty.

Funkcje systemu automatycznego

Działanie może mieć (i z reguły jest) kilka celów. Każdy użyteczny wynik wykraczający poza samo działanie można uznać za jego cel. Jeśli więc kasjer nie tylko sprzedaje bilety, ale także na koniec dnia pracy przygotowuje dla kierownictwa raport ze sprzedaży, sporządzenie raportu dziennego można uznać za kolejny cel działalności.

Jeśli na biurku kasjera postawimy komputer i drukarkę, a szef kasjerki wyda jej polecenie przepisywania biletów i raportów w edytorze tekstu i drukowania ich na drukarce, to otrzymamy zautomatyzowany system. Według współczesnych wyobrażeń jest bardzo prymitywny, formalnie będzie odpowiadał definicji Gosta. Należy pamiętać, że cele działania nie uległy zmianie w wyniku wdrożenia zautomatyzowanego systemu, zmienił się jedynie sposób ich osiągnięcia. To, co wcześniej było robione „tak po prostu”, teraz odbywa się w ramach zautomatyzowanego systemu. Zestaw działań zautomatyzowanego systemu mającego na celu osiągnięcie określonego celu, zgodnie z GOST 34.003-90, nazywa się jego funkcjonować. Uwaga: bez względu na to, jak na to spojrzeć, personel jest uważany za część systemu.

Funkcja zautomatyzowanego systemu jest podstawową koncepcją w GOST 34. Zautomatyzowany system jest rozpatrywany przede wszystkim jako suma jego funkcji, a dopiero potem jako zbiór „oprogramowania” i „sprzętu”. Najważniejsze jest to, co system robi, a to, z czego się składa, jest sprawą drugorzędną.

Powyższe mogłoby doprowadzić czytelnika do wniosku, że każdemu celowi działania w zautomatyzowanym systemie odpowiada jedna i tylko jedna funkcja. Taki system łatwo sobie wyobrazić, ale praktyka jest bardziej zróżnicowana. Z jednej strony działania nie zawsze są w pełni zautomatyzowane. Nawet po wdrożeniu zautomatyzowanego systemu niektóre cele trzeba osiągnąć ręcznie. Z drugiej strony, ponieważ ten sam wynik w różnych warunkach można osiągnąć na różne sposoby, kilka funkcji można nakierować na jeden cel działania w zautomatyzowanym systemie, na przykład sprzedaż biletu w kasie i sprzedaż biletu w kasie Internet. Ponadto każdy zautomatyzowany system wymaga pewnej konserwacji, dlatego musimy wprowadzić koncepcję funkcji pomocniczej. Typowym przykładem jest utworzenie kopii zapasowej danych.

Zadania systemu automatycznego

Ogólnie rzecz biorąc, podczas pełnienia funkcji część pracy jest wykonywana przez personel, a część przez technologię; powiedzmy, bilet jest drukowany automatycznie i przekazywany kupującemu ręcznie przez kasjera. Ciąg automatycznych (sic!) działań prowadzących do wyniku danego typu nazywa się w GOST 34.003-90 zadanie.

Tutaj definicja problemu nie jest przytoczona do końca trafnie, ale na razie to nam wystarczy, przecież nikomu nie jest wstydem przeczytać normę samodzielnie. Ważne jest, aby zadanie było jak najbardziej sformalizowaną częścią zautomatyzowanego działania. Można sobie wyobrazić funkcję wykonywaną całkowicie automatycznie, taką jak wspomniana powyżej kopia zapasowa. W tym przypadku funkcja jest zredukowana do jednego zadania.

To samo zadanie można rozwiązać, wykonując różne funkcje. Przykładowo, jeśli zautomatyzowany system posiada kilka funkcji sprzedaży biletu, wówczas wykonanie każdej z nich może w pewnym momencie wymagać wydrukowania biletu.

Skład systemu automatycznego

Podsystemy

Jeśli zautomatyzowany system jest dość złożony, dzieli się go na podsystemy. Co to znaczy, dość skomplikowane, dość trudno powiedzieć. Teoria systemów opisuje różne poziomy i kryteria złożoności. W praktyce konieczność rozmieszczenia kilku podsystemów w systemie zautomatyzowanym często wynika ze względów organizacyjnych i finansowych, np. podsystemy są opracowywane i uruchamiane sekwencyjnie.

Chociaż w GOST 34 termin podsystem jest używany wielokrotnie, wydaje się, że nie ma tam formalnej definicji tego pojęcia. Doświadczenie podpowiada, że ​​podsystem jest częścią systemu zautomatyzowanego, która również spełnia definicję systemu zautomatyzowanego, w szczególności posiada pełnowartościowe funkcje.

Wracając do przykładu biletowego, możemy stwierdzić, że zautomatyzowany system składa się z dwóch podsystemów: podsystemu biletowego i podsystemu raportowania dziennego. Przyjmijmy dla większej przejrzystości, że kasjer wpisuje bilety w edytorze tekstu, a raporty w arkuszach kalkulacyjnych.

składniki

Identyfikacja celów działania, funkcji zautomatyzowanego systemu i ewentualnie jego podsystemów ma charakter w dużej mierze subiektywny i zależy od punktu widzenia podmiotu, który się na to zdecydował. Jeśli jakiś wynik jest ważny w kontekście rozwiązywanego problemu, możemy uznać go za cel, w przeciwnym razie go zignorować. Zautomatyzowany system będziemy także rozbijać na podsystemy w dogodny dla nas sposób, o ile nasze decyzje nie będą sprzeczne z treścią tej koncepcji.

Komponenty to części, z których w obiektywnej rzeczywistości budujemy zautomatyzowany system. System fizycznie składa się ze swoich komponentów, dlatego podział zautomatyzowanego systemu na komponenty jest jak najbardziej obiektywny.

Kupujemy każdy komponent, instalujemy go i podłączamy (jeśli jest to sprzęt), instalujemy (jeśli jest to program) i konserwujemy go oddzielnie od innych komponentów. Kupiliśmy i położyliśmy komputer na stole - jest to podzespół. Opracowaliśmy specjalny edytor tekstu do wpisywania biletów - kolejny komponent. Pobrane darmowe arkusze kalkulacyjne z Internetu - znowu komponent. I nawet sama kasjerka jest w pewnym sensie także elementem zautomatyzowanego systemu.

Skład komponentów zautomatyzowanego systemu jest bardzo ważny z punktu widzenia jego dokumentacji, ponieważ dokumentacja techniczna systemu jako takiego i komponentów jest traktowana inaczej. Zwykle musi być opracowywany przez różne osoby i jest projektowany według różnych standardów, w zależności od typu komponentu.

Rodzaje zabezpieczeń

Jedną z najtrudniejszych koncepcji dla początkującego użytkownika GOST 34 jest rodzaj zabezpieczenia. Co to za zabezpieczenie? Czy możesz to zobaczyć lub dotknąć? Sprzedać czy kupić?

Każdy rodzaj oprogramowania łączy w sobie komponenty lub rozwiązania techniczne o określonym charakterze. GOST 34 wymienia wiele różnych rodzajów zabezpieczeń, nie będziemy tutaj opisywać każdego z nich po kolei, ale wymienimy tylko najbardziej zauważalne:

• wsparcie informacyjne – wszelkie dane i metadane, z którymi współpracuje system;
• oprogramowanie – wszystkie programy wchodzące w skład systemu;
• wsparcie techniczne - wszelkie środki techniczne (inaczej sprzęt, sprzęt) wchodzące w skład systemu.

Powtórzmy jeszcze raz, to nie wszystkie rodzaje zabezpieczeń. Nie możemy nawet powiedzieć z całą pewnością, że są najważniejsze. Na przykład wsparcie metrologiczne ma ogromne znaczenie w zautomatyzowanych systemach kontroli procesów (APCS). Wiele zautomatyzowanych systemów wymaga złożonego wsparcia matematycznego i językowego. Trudno jednak wyobrazić sobie zautomatyzowany system, który byłby całkowicie pozbawiony jednego z trzech wymienionych powyżej rodzajów wsparcia (ćwiczenie: spróbuj).