Uruchomienie systemu informatycznego. Uruchomienie systemów informatycznych gost

Procedura uruchomienia EIS.

TYPOWE PROJEKTOWANIE AUTOMATYCZNE. ETAP ROZRUCHU.

WYKŁAD 10.

Według GOST 34.601-90 „AS. Etapy tworzenia” i GOST 34.603-92 „Rodzaje testów elektrowni jądrowych” W ramach etapu uruchomienia systemu wykonywane są następujące prace:

1) przygotowanie organizacyjne obiektu automatyki do uruchomienia SI – wdrożenie decyzji projektowych dotyczących struktury organizacyjnej, zaopatrzenie działów obiektu sterowania w materiały instruktażowe i metodyczne, wprowadzenie klasyfikatorów informacji;

2) szkolenie personelu - szkolenie personelu i weryfikacja jego zdolności do zapewnienia funkcjonowania SI;

3) kompletny zestaw IS z dostarczonymi produktami (w przypadku konieczności takiej dostawy opisanej w SIWZ) - odbiór elementów produkcji seryjnej i jednostkowej, materiałów i wyrobów montażowych, prowadzenie kontroli jakości przyjęć;

4) prace budowlane i instalacyjne – prowadzenie prac związanych z budową specjalistycznych lokali mieszkalnych środki techniczne i personel IS, budownictwo kanały kablowe, montaż środków technicznych i linii komunikacyjnych, badania zainstalowanych środków technicznych, dostawa środków technicznych do uruchomienia;

5) prace rozruchowe – autonomiczna regulacja parametrów technicznych i narzędzia oprogramowania, ładowanie informacji do bazy danych i sprawdzanie jej utrzymania, kompleksowa regulacja wszystkich narzędzi systemowych;

6) przeprowadzenie wstępnych testów – testowanie SI pod kątem operatywności i zgodności z zakresem zadań zgodnie z programem i metodyką badań wstępnych; rozwiązywanie problemów i wprowadzanie zmian w dokumentacji SI, w tym dokumentacji eksploatacyjnej zgodnie z protokołem badań; rejestracja aktu o przyjęciu własności intelektualnej do eksploatacji próbnej;

7) operacja próbna – próbna eksploatacja IS; analiza jego wyników; rewizja oprogramowanie IP; dodatkowe dostosowanie środków technicznych SI; rejestracja zaświadczenia o zakończeniu eksploatacji próbnej.

8) testy akceptacyjne – badania na zgodność ze specyfikacjami technicznymi zgodnie z programem i metodologią badań akceptacyjnych; analiza wyników testów SI i eliminacja zidentyfikowanych podczas testów niedociągnięć; wykonanie ustawy o przyjęciu własności intelektualnej do stałej eksploatacji.

Uruchomienie EIS to stopniowe przejście od istniejącego systemu sterowania do zautomatyzowanego. Zwiększa to nie tylko stopień wykorzystania środków technicznych do przetwarzania danych, ale również same metody zarządzania odpowiednio się zmieniają.

Według modelu spiralnego koło życia systemy, począwszy od etapu projektowania technicznego, podsystemy EIS, zespoły zadań lub poszczególne komponenty zdolne do samodzielnego funkcjonowania, są oddawane do eksploatacji etapami, w miarę przygotowania dokumentacji roboczej i środków technicznych.

Etap rozruchu obejmuje próbną eksploatację kompleksów zadań oraz ich przyjęcie do eksploatacji komercyjnej po przeprowadzeniu testów odbiorczych. Cały system zostaje dopuszczony do eksploatacji komercyjnej po zakończeniu rozruchu wszystkich zestawów zadań.

Jedną z ważnych cech uruchomienia systemu jest obecność pewnego okresu, w którym istniejący system i nowy EIS działają równolegle. W systemach technicznych jedno urządzenie jest zastępowane drugim najczęściej sekwencyjnie w czasie. Czasami w miejsce starej instalowana jest nowa maszyna - w takim przypadku przez jakiś czas nie działa ani nowy, ani stary sprzęt. Jeśli nowy zacznie działać, zanim stary przestanie działać, wówczas będą działać niezależnie od siebie. Przy uruchamianiu EIS typu organizacyjnego zasadniczo niemożliwa jest sytuacja, w której ani stary, ani nowy system nie działał przynajmniej przez krótki czas. Ponadto w celu weryfikacji poprawności wszystkich rozwiązań wbudowanych przeprowadzamy uruchomienie nowy system przeprowadzane stopniowo podczas eksploatacji próbnej w następujących krokach:

1. Sprawdzenie podsystemu lub zestawu zadań na pełnej ilości rzeczywistych danych, ale nie w czasie rzeczywistym wymaganym do zarządzania.

2. Działanie nowego systemu na pełnej ilości danych rzeczywistych iw czasie rzeczywistym w trybie sterowania, w którym uzyskane wyniki nie są wykorzystywane do sterowania, lecz są porównywane z wynikami uzyskanymi w stary układ i są analizowane.

3. Przejście do zarządzania w oparciu o wyniki nowego systemu przy zachowaniu działania starego systemu w przypadku ewentualnych awarii i nieprzewidzianych sytuacji.

4. Ostateczne przejście do działania nowego systemu.

Praca systemu w trybie równoległym jest wyjątkowo niekorzystna dla pracowników. Muszą wykonywać podwójną pracę ze zwiększonym obciążeniem pracą. Twórcy systemu powinni dążyć do skrócenia okresu pracy równoległej, który w znacznym stopniu zależy od tego, jak pomyślnie przeprowadzono rozwój i debugowanie systemu. Niedopuszczalne jest przekazywanie choćby części debugowania i dostrajania systemu na okres próbnej eksploatacji. Zmiany w tym okresie są nieuniknione, ale należy dążyć do tego, aby pozostały tylko te, których nie można było przewidzieć przed rozpoczęciem eksploatacji próbnej.

Operacja próbna zastępuje proces testowania. Z reguły system jest uruchamiany nie do końca, stopniowo. Dlatego z punktu widzenia zawartości informacyjnej systemu uruchomienie przebiega przez co najmniej trzy fazy:

2) gromadzenie informacji;

3) osiągnięcie zdolności projektowej.

Podczas gromadzenie informacji pokaże największą liczbę błędów popełnionych podczas tworzenia System informacyjny. Z reguły są to błędy związane z dostępem dla wielu użytkowników. Często na etapie testowania takim błędom nie poświęca się należytej uwagi. Wynika to najwyraźniej ze złożoności modelowania, a także wysokich kosztów narzędzi do automatyzacji testowania systemu informatycznego w warunkach dostępu wielu użytkowników. Niektóre błędy będą dość trudne do naprawienia, ponieważ są to błędy projektowe. Żaden z najlepszych projektów nie jest przed nimi odporny. Oznacza to, że na wszelki wypadek należy zarezerwować czas na lokalizację i poprawienie takich błędów.

W okresie akumulacji informacji można spotkać się ze słynnym „załamaniem bazy”. W najgorszym przypadku okazuje się, że DBMS nie wytrzyma przepływu informacji. Jeśli jest dobrze, to po prostu źle skonfigurowane parametry. Pierwszy przypadek jest niebezpieczny, ponieważ dość trudno jest wpłynąć na producenta DBMS, a klient bardzo nie lubi powoływania się na serwis pomoc techniczna DBMS. To nie producent będzie musiał rozwiązać problem awarii DBMS, ale Ty - zmień schemat, zmniejsz przepływ żądań, zmień same żądania; ogólnie - jest wiele opcji. Dobrze, jeśli czas odtwarzania bazy danych mieści się w planowanym czasie projektu.

Wyjście systemu do wydajności projektowej na W szczęśliwym zbiegu okoliczności jest to korekta szeregu drobnych błędów, a czasami poważnych błędów.

RZĄD MOSKWY

ZAMÓWIENIE

W sprawie wymagań dotyczących uruchamiania systemów informatycznych tworzonych w Moskwie *

Dokument zmieniony przez:
(Biuletyn Burmistrza i Rządu Moskwy, N 37 (t. 2), 07.07.2015);
(Biuletyn Prezydenta Miasta i Rządu Moskwy, N 57, 13.10.2015);
z dnia 05.12.2017 N 694-RP (Oficjalna strona internetowa burmistrza i rządu Moskwy www.mos.ru. 06.12.2017);
(Oficjalna strona internetowa burmistrza i rządu Moskwy www.mos.ru, 20.12.2018).
____________________________________________________________________

________________

* Nazwa w brzmieniu wprowadzonym w życie zarządzeniem Rządu Moskwy z dnia 30 czerwca 2015 r. N 370-RP ..


W celu poprawy efektywności działania systemów informatycznych w mieście Moskwa:

1. Ustal, że:

1.1. Władze wykonawcze miasta Moskwy, które zapewniają tworzenie systemów informatycznych na koszt budżetu miasta Moskwy, organizacje podległe takim władzom wykonawczym miasta Moskwy, które zgodnie z aktami prawnymi miasta Moskwy Moskwa, są uprawnieni do zapewnienia tworzenia systemów informatycznych (zwanych dalej także organami wykonawczymi miasta Moskwy i organizacjami zapewniającymi tworzenie systemów informatycznych), przeprowadzają uruchomienie tych systemów informatycznych po przeprowadzeniu testów akceptacyjnych potwierdzających gotowości systemu informatycznego do uruchomienia, zatwierdzenia modelu zagrożenia bezpieczeństwa informacji i wykonania niezbędne czynności w sprawie ochrony informacji zawartych w systemie informatycznym poprzez wydawanie aktów prawnych (przepisów lokalnych) odpowiednio władz wykonawczych miasta Moskwy lub organizacji zapewniających tworzenie systemów informatycznych (zwanych dalej aktami prawnymi w sprawie zlecania informacji systemy) w formie zgodnej z Załącznikiem do niniejszego zamówienia.
Dekret Rządu Moskwy z dnia 19 grudnia 2018 r. N 891-RP.

1.2. Akty prawne dotyczące uruchamiania systemów informatycznych, których tworzenia nie zapewnia Wydział Technologii Informacyjnych Miasta Moskwy, podlegają uzgodnieniu z Wydziałem Technologii Informacyjnych Miasta Moskwy. W trakcie koordynacji przez Departament Technologii Informacyjnych Miasta Moskwy dodatkowe informacje o tym systemie informatycznym zawierające jego opis i (lub) potwierdzające podstawy jego utworzenia, a także zgodność kosztów stworzenia systemu informatycznego planowany koszt prac nad rozwojem systemów informatycznych tworzonych w mieście Moskwa, ustalony zgodnie z Metodologią obliczania planowanych kosztów prac nad tworzeniem, rozwojem i modernizacją systemów informatycznych w mieście Moskwa, zatwierdzony przez wspólne zamówienie Wydziału Polityki Gospodarczej i Rozwoju Miasta Moskwy oraz Wydziału Technologii Informacyjnych Miasta Moskwy.
(Klauzula zmieniona Dekretem Rządu Moskwy z dnia 19 grudnia 2018 r. N 891-RP.

1.3. W przypadku, gdy korzystanie z systemu informacyjnego będzie prowadzone przez kilka organów wykonawczych miasta Moskwy lub podczas korzystania z systemu informacyjnego planowana jest interakcja z mieszkańcami miasta Moskwy i / lub osoby prawne, władza wykonawcza miasta Moskwy, która zapewnia tworzenie systemu informacyjnego lub pełni funkcje i uprawnienia założyciela podległej organizacji zapewniającej tworzenie systemu informacyjnego, w porozumieniu z Departamentem Technologii Informatycznych miasto Moskwa poddaje się we właściwym czasie do rozpatrzenia przez Rząd Moskwy projekt aktu prawnego Rządu Moskwy zawierającego zapis dotyczący określonego systemu informatycznego, w którym m.in. uczestników wymiana informacji korzystania z systemu informatycznego oraz posiadanych uprawnień, w tym uprawnień do przetwarzania danych osobowych zawartych w systemie informatycznym.
Dekret Rządu Moskwy z dnia 19 grudnia 2018 r. N 891-RP.

W przypadku, gdy akt prawny Rządu Moskwy określa władzę wykonawczą miasta Moskwy odpowiedzialną za porządkowanie zawartości informacyjnej systemu informatycznego, organ organizujący przetwarzanie danych osobowych zawartych w systemie informatycznym, określa cele przetwarzania takich danych osobowych, a także uprawnienia właściciela informacji zawartych w systemie informatycznym są przypisane do określonego organu wykonawczego miasta Moskwy. Jednocześnie uprawnienie do zastosowania środków technicznych zapewniających bezpieczeństwo danych osobowych podczas ich przetwarzania w systemie informatycznym, niezbędnych do spełnienia wymagań ochrony danych osobowych ustanowionych przez Rząd Federacja Rosyjska są przypisane do operatora systemu informatycznego.
(Akapit w brzmieniu wprowadzonym w życie zarządzeniem Rządu Moskwy z dnia 6 października 2015 r. N 563-RP.
(Klauzula 1.3 zmieniona Dekretem Rządu Moskwy z dnia 30 czerwca 2015 r. N 370-RP.

1.3(1). Środki ochrony informacji zawartych w systemach informatycznych wdrożone przez organ wykonawczy miasta Moskwy odpowiedzialny za organizację zawartości informacyjnej systemu informacyjnego obejmują:

Akapit jest już nieaktualny -.;

Paragraf stracił ważność - zarządzenie Rządu Moskwy z dnia 19 grudnia 2018 r. N 891-RP.;

Paragraf stracił ważność - zarządzenie Rządu Moskwy z dnia 19 grudnia 2018 r. N 891-RP.;

Paragraf stracił ważność - zarządzenie Rządu Moskwy z dnia 19 grudnia 2018 r. N 891-RP.;

- określenie stopnia możliwej szkody (możliwych negatywnych konsekwencji) naruszenia poufności, integralności lub dostępności informacji dla każdego rodzaju informacji;
(Akapit jest dodatkowo zawarty w zarządzeniu Rządu Moskwy z dnia 19 grudnia 2018 r. N 891-RP)

- ocena szkód, jakie mogą zostać wyrządzone podmiotom danych osobowych w przypadku naruszenia wymogów ustawodawstwa Federacji Rosyjskiej w zakresie danych osobowych;
(Akapit jest dodatkowo zawarty w zarządzeniu Rządu Moskwy z dnia 19 grudnia 2018 r. N 891-RP)

Określenie wymagań dla systemu informatycznego (podsystemu) w zakresie ochrony informacji zawartych w systemie informatycznym.
(Pozycja dodatkowo dołączona)

1.4. Jeżeli nie ma podstaw do przyjęcia aktu prawnego Rządu Moskwy zawierającego postanowienie o systemie informatycznym, akt prawny o uruchomieniu systemu informatycznego musi zostać uzgodniony z władzą wykonawczą miasta Moskwy, która zapewnia obsługa systemu informatycznego na koszt budżetu miasta Moskwy lub z podmiotem podległym władzy wykonawczej miasta Moskwy przez organizację (jeśli posiada odpowiednie uprawnienia).
(Klauzula 1.4 jest dodatkowo uwzględniona w Dekrecie Rządu Moskwy z dnia 30 czerwca 2015 r. N 370-RP na mocy Dekretu Rządu Moskwy z dnia 6 października 2015 r. N 563-RP; zmieniona Dekretem Rządu Moskwy z grudnia 2015 r. 19.2018 N 891-RP.

1.5. Dostęp do informacji zawartych w systemie informatycznym jest zapewniany po uruchomieniu systemu informatycznego przez operatora systemu informatycznego lub organizację przez niego upoważnioną do pełnienia funkcji operatora systemu informatycznego, poprzez:

Swobodny dostęp do informacji niezwiązanych z informacją ograniczony dostęp o ile inaczej nie wynika z rozporządzenia o systemie informatycznym;

Uzyskiwanie informacji przez władze wykonawcze miasta Moskwy, podległe im organizacje, inne organizacje, osoby zgodnie z rozporządzeniem o systemie informatycznym;

Pozyskiwanie informacji na podstawie umów o użytkowanie zasoby informacji systemu informatycznego zawieranych przez operatora systemu informatycznego lub organizację przez niego upoważnioną do pełnienia funkcji operatora systemu informatycznego, z podmiotami gospodarczymi (zwana dalej umową o korzystanie z zasobów informacyjnych).
(Klauzula 1.5 jest dodatkowo zawarta w Dekrecie Rządu Moskwy z dnia 30 czerwca 2015 r. N 370-RP)

1.6. Umowa o korzystaniu z zasobów informacyjnych jest umową akcesyjną i powinna między innymi przewidywać:

Wykaz systemów informatycznych, z których informacje podlegają udostępnieniu;

Skład informacji, do których zapewniany jest dostęp;

Cel udostępnienia informacji;

Wysokość opłaty za udostępnienie informacji, jeżeli operator systemu informatycznego nie ustalił, że udostępnienie jest nieodpłatne;

Wymogi i ograniczenia dotyczące wykorzystywania informacji, w tym przy wykonywaniu działalności przez podmiot gospodarczy.
(Klauzula 1.6 jest dodatkowo zawarta w zarządzeniu Rządu Moskwy z dnia 30 czerwca 2015 r. N 370-RP)

1.7. Operator systemu informatycznego zapewnia zatwierdzanie wzorów umów o korzystanie z zasobów informacyjnych i ich umieszczanie na oficjalnej stronie internetowej operatora systemu informatycznego w sieci teleinformatycznej Internet, zawieranie umów o korzystanie z zasobów informacyjnych oraz kontrolę nad ich wykonanie. Określone uprawnienia są wykonywane przez operatora systemu informatycznego, niezależnie od tego, czy akt prawny Rządu Moskwy zawierający rozporządzenie w sprawie systemu informatycznego określa inną władzę wykonawczą miasta Moskwy niż operator systemu informatycznego i odpowiada za organizację zawartości informacyjnej systemu informacyjnego.
(Klauzula 1.7 jest dodatkowo zawarta w zarządzeniu Rządu Moskwy z dnia 30 czerwca 2015 r. N 370-RP)

1.8. W ramach umowy o korzystanie z zasobów informacyjnych dane osobowe i inne informacje o ograniczonym dostępie nie są udostępniane, chyba że takie udostępnienie zostało uzgodnione z podmiotem danych osobowych lub właścicielem informacji o ograniczonym dostępie.
(Klauzula 1.8 jest dodatkowo zawarta w zarządzeniu Rządu Moskwy z dnia 30 czerwca 2015 r. N 370-RP)

1.9. Akt prawny Rządu Moskwy, zawierający rozporządzenie w sprawie systemu informatycznego, może ustanowić inne cechy udostępniania informacji zawartych w systemie informatycznym.
(Klauzula 1.9 jest dodatkowo zawarta w Dekrecie Rządu Moskwy z dnia 30 czerwca 2015 r. N 370-RP)

2. Nałożyć kontrolę nad wykonaniem niniejszego zarządzenia na Ministra Rządu Moskwy, naczelnika Wydziału Informatyki Miasta Moskwy Łysenko E.A.
(Klauzula zmieniona Dekretem Rządu Moskwy z dnia 19 grudnia 2018 r. N 891-RP.

Burmistrz Moskwy
SS Sobianin

Aplikacja. O uruchomieniu

Aplikacja
na rozkaz rządu moskiewskiego
z dnia 3 lipca 2012 r. N 342-RP
(zmieniony przez
na rozkaz rządu moskiewskiego
z dnia 5 grudnia 2017 r. N 694-RP;
zmieniony przez
na rozkaz rządu moskiewskiego
z dnia 19 grudnia 2018 r. N 891-RP. -
Zobacz poprzednie wydanie)

Rewizja dokumentu, biorąc pod uwagę
przygotowane zmiany i uzupełnienia
CJSC „Kodeks”

Dekret Rządu Federacji Rosyjskiej z dnia 6 lipca 2015 r. N 676
„O wymaganiach dotyczących trybu tworzenia, rozbudowy, uruchamiania, eksploatacji i likwidacji systemów informatycznych państwa oraz dalszego przechowywania informacji zawartych w ich bazach danych”

Zgodnie z częścią 6 art. 14 ustawy federalnej „O informacji, technologiach informacyjnych i ochronie informacji” rząd Federacji Rosyjskiej postanawia:

1. Zatwierdzić załączone wymagania dotyczące trybu tworzenia, rozwoju, uruchamiania, eksploatacji i likwidacji systemów informacji państwowej oraz dalszego przechowywania informacji zawartych w ich bazach danych.

2. Stwierdzenie, że środki przewidziane w wymaganiach zatwierdzonych niniejszą uchwałą są realizowane przez federalne organy wykonawcze w ramach środków budżetowych przewidzianych w ustawie federalnej o budżecie federalnym na odpowiedni rok budżetowy i okres planowania przywództwa i zarządzania w zakres ustalonych funkcji.

3. Zalecać innym organom państwowym, oprócz federalnych organów wykonawczych i organów wykonawczych podmiotów wchodzących w skład Federacji Rosyjskiej, a także organom zarządzającym państwowymi funduszami pozabudżetowymi, samorządom terytorialnym, kierować się w swojej działalności wymaganiami zatwierdzonymi niniejszą uchwałą.

Wymagania
na zlecenie tworzenia, rozbudowy, uruchamiania, eksploatacji i likwidacji państwowych systemów informatycznych oraz dalszego przechowywania informacji zawartych w ich bazach danych
(zatwierdzony dekretem rządu Federacji Rosyjskiej z dnia 6 lipca 2015 r. N 676)

Ze zmianami i dodatkami od:

I. Postanowienia ogólne

1. Niniejszy dokument określa wymagania dotyczące trybu realizacji działań w zakresie tworzenia, rozwoju, uruchamiania, eksploatacji i likwidacji systemów informatycznych państwa (zwanych dalej systemem) oraz dalszego przechowywania informacji zawartych w ich bazach, realizowanych przez federalne władze wykonawcze i organy wykonawcze władze podmiotów wchodzących w skład Federacji Rosyjskiej (zwane dalej władzami wykonawczymi) w celu zwiększenia efektywności wykonywania uprawnień władz wykonawczych w wyniku wykorzystania technologii informacyjno-komunikacyjnych , albo przez organy wykonawcze działające jako partnerzy publiczni i partnerzy prywatni zgodnie z umowami o partnerstwie publiczno-prywatnym (dalej - partner prywatny) w celu realizacji tych umów.

1.1. Gdy organy wykonawcze lub partnerzy prywatni wdrażają działania mające na celu tworzenie, rozwój, uruchamianie, eksploatację i likwidację systemów oraz dalsze przechowywanie informacji zawartych w ich bazach danych, należy wykonać następujące czynności:

a) wymagania dotyczące ochrony informacji zawartych w systemach ustanowionych przez federalny organ wykonawczy w dziedzinie bezpieczeństwa oraz federalny organ wykonawczy upoważniony w zakresie przeciwdziałania wywiadu technicznego i technicznej ochrony informacji, w granicach ich kompetencji;

b) wymagania dotyczące organizacji i środków ochrony informacji zawartych w systemie;

Informacje o zmianach:

Ustęp 1.1 został uzupełniony o podpunkt „c” z dnia 27 kwietnia 2019 r. – Uchwała

c) wymagania dotyczące ochrony danych osobowych, przewidziane w części 3 art. 19 ustawy federalnej „O danych osobowych” (jeśli w systemie znajdują się dane osobowe).

Informacje o zmianach:

Dekret Rządu Federacji Rosyjskiej z dnia 11 maja 2017 r. N 555 Wymagania uzupełnia klauzula 1.2

1.2. W celu spełnienia wymagań ochrony informacji przewidzianych w pkt 1.1 niniejszego dokumentu (zwanych dalej wymaganiami ochrony informacji) organy wykonawcze określają wymagania ochrony informacji zawartych w systemie organ wykonawczy, na rzecz którego wykonują:

a) określenie informacji, które mają być chronione przed nieupoważnionym dostępem, zniszczeniem, modyfikacją, blokowaniem, kopiowaniem, udostępnianiem, dystrybucją, a także innymi działaniami niezgodnymi z prawem w stosunku do tych informacji;

b) analizę regulacyjnych aktów prawnych, dokumentów metodycznych oraz norm krajowych, które system musi spełniać;

c) klasyfikację systemu zgodnie z wymaganiami dotyczącymi bezpieczeństwa informacji;

d) identyfikacja zagrożeń bezpieczeństwa informacji, których realizacja może doprowadzić do naruszenia bezpieczeństwa informacji w systemie oraz opracowanie na ich podstawie modelu zagrożeń bezpieczeństwa informacji;

e) określenie wymagań dla systemu informatycznego (podsystemu) ochrony informacji zawartych w systemie.

II. Wymagania dotyczące kolejności tworzenia systemu

2. Podstawą powstania systemu jest:

a) obowiązek władzy wykonawczej do stworzenia systemu, przewidziany w regulacyjnych aktach prawnych;

b) decyzji organu władzy wykonawczej o utworzeniu systemu w celu zapewnienia realizacji przyznanych mu uprawnień;

Informacje o zmianach:

Ustęp 2 został uzupełniony o podpunkt „c” z dnia 27 kwietnia 2019 r. - Dekret Rządu Rosji z dnia 11 kwietnia 2019 r. N 420

c) decyzja Rządu Federacji Rosyjskiej o realizacji projektu partnerstwa publiczno-prywatnego;

Informacje o zmianach:

Ustęp 2 został uzupełniony o podpunkt „d” z dnia 27 kwietnia 2019 r. - Dekret Rządu Rosji z dnia 11 kwietnia 2019 r. N 420

d) decyzja najwyższego organu wykonawczego władzy państwowej podmiotu wchodzącego w skład Federacji Rosyjskiej, jeżeli partner publiczny jest podmiotem wchodzącym w skład Federacji Rosyjskiej lub planowany jest wspólny przetarg z udziałem podmiotu wchodzącego w skład Federacji Rosyjskiej (z wyjątkiem przypadków, gdy organizowany jest wspólny przetarg z udziałem Federacji Rosyjskiej).

3. Tworzenie systemu odbywa się zgodnie z zakresem zadań, z uwzględnieniem modelu zagrożenia bezpieczeństwa informacji, o którym mowa w punkcie „d” ust. 1.2 niniejszego dokumentu, a także stopni ochrony danych osobowych podczas ich przetwarzania w systemach informatycznych danych osobowych, w zależności od zagrożeń dla bezpieczeństwa tych danych oraz wymagań niniejszego dokumentu.

Model zagrożenia bezpieczeństwa informacji i (lub) zakres zadań do stworzenia systemu są uzgadniane z federalnym organem wykonawczym w dziedzinie bezpieczeństwa oraz federalnym organem wykonawczym uprawnionym w zakresie przeciwdziałania wywiadowi technicznemu i technicznej ochrony informacji, w granicach swoich uprawnień w części związanej z realizacją ustalonych wymagań ochrony informacji.

Zakres wymagań i obowiązków dotyczących stworzenia systemu musi zawierać wymagania dotyczące ochrony informacji zawartych w systemie, utworzone zgodnie z podpunktami „a” i „c” paragrafu 1.1 niniejszego dokumentu.

4. Zakres zadań tworzenia systemu oraz model zagrożeń bezpieczeństwa informacji zatwierdza urzędnik organu wykonawczego, któremu powierzono odpowiednie uprawnienia.

5. Procedura tworzenia systemu obejmuje następujące kolejno realizowane kroki:

a) opracowanie dokumentacji systemu i jego części;

b) opracowanie dokumentacji roboczej systemu i jego części;

c) rozwój lub adaptacja oprogramowania;

d) uruchomienie;

e) przeprowadzenie wstępnych testów systemu;

f) przeprowadzenie próbnej eksploatacji systemu;

g) wykonanie testów akceptacyjnych systemu.

6. Etap opracowania dokumentacji systemu i jego części obejmuje opracowanie, zatwierdzenie i zatwierdzenie dokumentacji w ilości niezbędnej do opisania pełnego zestawu rozwiązań projektowych (w tym bezpieczeństwa informacji) i wystarczającej do dalszych prac nad stworzeniem systemu.

7. Etap opracowania dokumentacji roboczej systemu i jego części obejmuje opracowanie, zatwierdzenie i zatwierdzenie dokumentacji zawierającej informacje niezbędne do wykonania prac przy uruchomieniu systemu i jego eksploatacji oraz procedury eksploatacji systemu, zawierającej informacje niezbędne wykonywać prace mające na celu utrzymanie poziomu charakterystyki operacyjnej (jakości) systemu (w tym bezpieczeństwa informacji) ustalonego w decyzjach projektowych określonych w paragrafie 6 niniejszego dokumentu, w tym:

a) wykaz działań pracowników przy wykonywaniu zadań związanych z obsługą systemu, w tym wykaz, rodzaje, wielkość i częstotliwość pracy wykonywanej w celu zapewnienia funkcjonowania systemu;

b) monitorowanie wydajności systemu i komponentów zapewniających ochronę informacji;

c) wykaz awarii, które mogą wystąpić podczas pracy systemu oraz zalecenia postępowania w przypadku ich wystąpienia;

d) wykaz trybów pracy systemu i ich charakterystykę, a także procedurę i zasady przechodzenia systemu z jednego trybu pracy do drugiego, ze wskazaniem czasu na to potrzebnego.

8. Etap tworzenia lub adaptacji oprogramowania obejmuje opracowanie oprogramowania systemowego, wybór i adaptację nabytego oprogramowania, a także w ustalonych przypadkach i w trybie certyfikację opracowanego oprogramowania systemowego i narzędzi ochrony informacji wymagania bezpieczeństwa.

9. Etap uruchomienia obejmuje dostosowanie offline sprzętu i oprogramowania części systemu, wgranie informacji do jego bazy danych, kompleksowe dostosowanie sprzętu i oprogramowania systemu, w tym narzędzi bezpieczeństwa informacji.

10. Etap wstępnych testów obejmuje:

a) opracowanie programu i metodologii testów wstępnych, zgodnie z którymi testowany jest system pod kątem operatywności i zgodności z zakresem zadań jego stworzenia;

b) sprawdzenie systemu pod kątem operacyjności i zgodności z zakresem uprawnień do jego utworzenia;

c) usunięcie stwierdzonych w trakcie tych testów awarii oraz zmiany w dokumentacji i dokumentacji roboczej systemu;

d) rejestracja protokołu z badań i akt przyjęcia systemu do eksploatacji próbnej.

11. Etap eksploatacji próbnej obejmuje:

a) opracowanie programu i metodyki eksploatacji próbnej;

b) próbnej eksploatacji systemu zgodnie z programem i metodologią próbnej eksploatacji;

c) finalizację oprogramowania systemowego oraz dodatkowe dostosowanie środków technicznych w przypadku wykrycia niedociągnięć stwierdzonych podczas próbnej eksploatacji systemu;

d) zarejestrowanie aktu o zakończeniu eksploatacji próbnej wraz z wykazem uchybień, które należy usunąć przed rozpoczęciem eksploatacji systemu.

12. Etap testów akceptacyjnych obejmuje:

a) testowanie systemu pod kątem zgodności z zakresem zadań jego stworzenia zgodnie z programem i metodologią testów akceptacyjnych;

b) analiza skutków usunięcia uchybień określonych w ustawie o zakończeniu próbnej eksploatacji;

c) zarejestrowanie aktu przyjęcia systemu do eksploatacji.

III. Wymagania dotyczące uruchomienia systemu

13. Podstawą uruchomienia systemu jest akt prawny organu wykonawczego o uruchomieniu systemu, który określa wykaz działań zapewniających rozruch systemu oraz określa termin rozpoczęcia eksploatacji.

14. Akt prawny organu wykonawczego w sprawie uruchomienia systemu zawiera:

a) środki opracowywania i zatwierdzania dokumentów organizacyjnych i administracyjnych, które określają środki ochrony informacji podczas działania systemu, których rozwój przewidują regulacyjne akty prawne i dokumenty metodologiczne federalnego organu wykonawczego w dziedzinie bezpieczeństwa i federalnego organu wykonawczego upoważnionego w zakresie przeciwdziałania wywiadowi technicznemu i technicznej ochrony informacji, a także krajowych standardów w zakresie ochrony informacji;

b) środki mające na celu certyfikację systemu pod kątem wymagań bezpieczeństwa informacji, w wyniku których, w przypadkach określonych przez ustawodawstwo Federacji Rosyjskiej, zgodność ochrony informacji zawartych w systemie z wymogami przewidzianymi przez ustawodawstwo Federacji Rosyjskiej Federacja Rosyjska w sprawie informacji, technologii informacyjnych i bezpieczeństwa informacji zostaje potwierdzona;

c) działania przygotowujące organ wykonawczy, a także partnera prywatnego na wypadek zawarcia umowy o partnerstwie publiczno-prywatnym do eksploatacji systemu;

d) działania mające na celu przeszkolenie urzędników władzy wykonawczej, a także pracowników partnera prywatnego w przypadku umowy o partnerstwie publiczno-prywatnym z obsługi systemu, w tym odpowiedzialnych za zapewnienie bezpieczeństwa informacji.

15. Uruchomienie systemu jest niedozwolone w następujących przypadkach:

a) nieprzestrzeganie wymogów bezpieczeństwa informacji ustanowionych przez ustawodawstwo Federacji Rosyjskiej, w tym brak ważnego certyfikatu zgodności z wymogami bezpieczeństwa informacji;

b) braku w rejestrze terytorialnym rozmieszczenia obiektów kontroli przewidzianym w Regulaminie sprawowania kontroli nad rozmieszczeniem środków technicznych systemów informatycznych wykorzystywanych przez organy państwowe, jednostki samorządu terytorialnego, państwowe i komunalne przedsiębiorstwa unitarne, instytucje państwowe i komunalne, na terytorium Federacji Rosyjskiej, zatwierdzony dekretem Rządu Federacji Rosyjskiej z dnia 6 lipca 2015 r. N 675 „W sprawie procedury monitorowania zgodności z wymogami przewidzianymi w części 2.1 artykułu 13 i części 6 artykułu 14 ustawy federalnej „O informacji, technologiach informacyjnych i ochronie informacji” informacje o rozmieszczeniu środków technicznych systemu informacyjnego na terytorium Federacja Rosyjska;

c) niezgodności z wymaganiami niniejszego rozdziału, stwierdzone w toku monitoringu zgodnie z Zasadami monitorowania spełniania wymagań dotyczących tworzenia, rozwoju, uruchamiania, eksploatacji i likwidacji państwowych systemów informatycznych oraz dalszego przechowywania informacji zawartych w swoich bazach danych zatwierdził dekret rządu Federacji Rosyjskiej z dnia 6 lipca 2015 r. N 675 „W sprawie procedury monitorowania zgodności z wymogami przewidzianymi w części 2.1 art. 13 i części 6 art. 14 ustawy federalnej” W dniu Informacja, technologie informacyjne i ochrona informacji” niniejszego dokumentu akt prawny a) przygotowanie aktów prawnych związanych z likwidacją systemu;

b) prace związane z likwidacją systemu, w tym prace związane z deinstalacją oprogramowania systemowego, wykonywaniem praw do oprogramowania systemowego, demontażem i likwidacją sprzętu systemowego, zapewnieniem przechowywania i dalszego korzystania z zasobów informacyjnych systemu;

Informacje o zmianach:

Dekretem Rządu Federacji Rosyjskiej z dnia 11 maja 2017 r. N 555 paragraf 23 został uzupełniony o literę „c”

c) zapewnienie ochrony informacji zgodnie z dokumentacją systemu oraz dokumentami organizacyjno-administracyjnymi dotyczącymi ochrony informacji, w tym archiwizację informacji zawartych w systemie, niszczenie (kasowanie) danych i informacji szczątkowych z nośników pamięci maszyn i (lub) niszczenie maszynowych nośników informacji.

24. O ile regulacyjne akty prawne Federacji Rosyjskiej nie stanowią inaczej, okresy przechowywania informacji zawartych w bazach danych systemu są ustalane przez organ wykonawczy i nie mogą być krótsze niż okresy przechowywania informacji ustalone dla przechowywania dokumentów w formie papierowej zawierających takie informacje.

25. Termin likwidacji systemu nie może być wcześniejszy niż termin zakończenia ostatniej czynności przewidzianej ustawą o likwidacji systemu.

Zastępca Dyrektora Departamentu Regulacji Państwowej w Gospodarce

Ministerstwo Rozwoju Gospodarczego Federacji Rosyjskiej
______________ V.N. Rudenko
« 09 » _ Listopad __ 2011

AKT WPROWADZENIA DO PRÓBNEJ EKSPLOATACJI

Zautomatyzowany system informatyczny zarządzania projektami opracowany w ramach umowy państwowej z dnia 07.11.2011 nr GK-158-OF/D01.
Zgodnie ze wspólną decyzją Klienta (Ministerstwo Rozwoju Gospodarczego Rosji) i Wykonawcy (OTR 2000 LLC) o wprowadzeniu do eksploatacji próbnej.

Komisja w składzie:

Przewodniczący Komisji:

Zastępca Dyrektora Departamentu Regulacji Państwowych w Gospodarce V.N. Rudenko,

Członkowie Komisji:

pełniący obowiązki Kierownika Wydziału Rozwoju Społeczeństwa Elektronicznego Departamentu Regulacji Państwowych w Gospodarce S.V. Puszczakow,

Doradca Departamentu Wsparcia Metodycznego Organizacji Współpracy Międzyresortowej Departamentu Regulacji Państwowej w Gospodarce A.V. Matwieenko,

Konsultant Wiodący Departamentu Rozwoju Społeczeństwa Elektronicznego Departamentu Regulacji Państwa w Gospodarce N.N. Kirsanowa,

Kierownik kierunku LLC „OTR 2000” A.I. Kuleszowa,

Kierownik projektu OTR 2000 LLC O.V. Strachowa,

Główny analityk OTR 2000 LLC Yu.M. Gudkowa,

Badacz kierunku „Real Sector” IEP im. E.T. Gaidara ER Batarszyn.
od "_ 08 _" Listopad 2011 przez „_ 09 _" Listopad W 2011 roku przeprowadzono wstępne testy oprogramowania aplikacyjnego dla zautomatyzowanego systemu informacyjnego „Portal zarządzania projektami” (AIS PPU), zainstalowanego w Ministerstwie Rozwoju Gospodarczego Rosji.

1. 
   Testy wstępne uznaje się za pomyślnie zakończone.

1. 
   Główne etapy rozwoju zostały zakończone zgodnie z SIWZ.
2. 
   Rozwinięty dokumentacja spełnia wymagania działanie oprogramowania.
3. 
   Oprogramowanie jest gotowe do pracy próbnej.

1. 
   Wykaz funkcji przyjętych do eksploatacji próbnej (sekcja „Wymagania dla funkcji realizowanych przez system” specyfikacji istotnych warunków zamówienia):
   1. 
      Prowadzenie listy projektów.
   2. 
      Praca z jednostkami projektowymi.
   3. 
      Praca ze wskaźnikami do oceny stanu prac nad projektem.
   4. 
      Moduł analityczny.
   5. 
      Biblioteka dokumentów.

1. 
   Wykaz dokumentów przekazanych komisji, niezbędnych do przeprowadzenia próbnej eksploatacji:
   1. 
      „Opis „Portalu zarządzania projektami” AIS” (Paszport Systemu);
   2. 
      „Instrukcja dla administratora AIS PPU”;
   3. 
      „Podręcznik użytkownika AIS PPU”;
   4. 
      „Program i metodologia testowania AIS PPU”;
   5. 
      „Zadania testowe dla AIS PPU”;
   6. 
      „Instrukcja roli opisująca procedurę pracy z AIS PPU jako narzędziem do zarządzania projektami” Interakcja międzywydziałowa „”.
2. 
   Decyzja Komisji: Dopuszczenie oprogramowania do eksploatacji próbnej od 9 listopada 2011 r.

APLIKACJE:

1. 
   Raport z badań wstępnych nr 1
2. 
   Raport z badań wstępnych nr 2

V.N. Rudenko

SV Puszczakow

AV Matwieenko

NN Kirsanowa

sztuczna inteligencja Kuleszow

OV Strachowa

mniam Gudkow

ostry dyżur Batarszyn

GOST 34.601-90

Grupa P87

STANDARD MIĘDZYNARODOWY

TECHNOLOGIA INFORMACYJNA

SYSTEMY AUTOMATYCZNE

ETAPY TWORZENIA

technologia informacyjna. Zestaw norm dla systemów zautomatyzowanych. zautomatyzowane systemy. Etapy rozwoju

MKS 35.080
OKSTU 0034

Data wprowadzenia 1992-01-01

DANE INFORMACYJNE

1. OPRACOWANY I WPROWADZONY przez Państwowy Komitet ZSRR ds. Zarządzania Jakością Produktów i Norm

2. ZATWIERDZONE I WPROWADZONE PRZEZ Dekret Państwowego Komitetu ZSRR ds. Zarządzania Jakością Produktów i Norm z dnia 29 grudnia 1990 r. N 3469

3. ZAMIAST GOST 24.601-86, GOST 24.602-86

4. PRZEPISY ODNIESIENIA I DOKUMENTY TECHNICZNE

6*. REPUBLIKACJA. lipiec 2009
________________
* Numeracja odpowiada oryginałowi. - Uwaga producenta bazy danych.

Niniejsza norma dotyczy zautomatyzowane systemy(AS) wykorzystywane w różnych działaniach (badania, projektowanie, zarządzanie itp.), w tym ich kombinacje tworzone w organizacjach, stowarzyszeniach i przedsiębiorstwach (dalej - organizacje).

Norma określa etapy i etapy tworzenia AS.

Załącznik 1 przedstawia treść pracy na każdym etapie.

1. POSTANOWIENIA OGÓLNE

1. POSTANOWIENIA OGÓLNE

1.1. Proces tworzenia AS to zbiór uporządkowanych w czasie, wzajemnie powiązanych, połączonych etapami i etapami prac, których realizacja jest konieczna i wystarczająca do stworzenia AS spełniającego określone wymagania.

1.2. Etapy i etapy tworzenia AS wyróżnia się jako części procesu tworzenia ze względu na racjonalne planowanie i organizację pracy, kończącej się określonym rezultatem.

1.3. Prace nad rozwojem AU prowadzone są zgodnie z etapami i etapami stosowanymi do tworzenia AU.

1.4. Skład i zasady wykonywania pracy na etapach i etapach określonych w niniejszym standardzie są określone w odpowiedniej dokumentacji organizacji zaangażowanych w tworzenie określonych typów elektrowni jądrowych.

Lista organizacji zaangażowanych w tworzenie UA znajduje się w Załączniku 2.

2. ETAPY I ETAPY TWORZENIA AS

2.1. Etapy i etapy tworzenia AS w ogólnym przypadku podano w tabeli.

2.2. Etapy i etapy wykonywane przez organizacje - uczestników tworzenia elektrowni jądrowych są ustalane w umowach i specyfikacjach istotnych warunków zamówienia opartych na tym standardzie.

Dopuszcza się wyłączenie etapu „Projekt wstępny” i wyodrębnienie etapów prac na wszystkich etapach, połączenie etapów „Projekt techniczny” i „Dokumentacja szczegółowa” w jeden etap „Projekt wykonawczy”. W zależności od specyfiki tworzonego AS i warunków ich powstania dopuszcza się wykonywanie poszczególnych etapów prac do czasu zakończenia poprzednich etapów, równoległe wykonywanie etapów prac w czasie, włączanie nowych etapów prac.

ZAŁĄCZNIK 1 (informacyjny). TREŚĆ PRAC

ANEKS 1
Odniesienie

1. Na etapie 1.1 „Inwentaryzacja obiektu i uzasadnienie potrzeby powstania EJ” w przypadku ogólnym przeprowadza się:

Gromadzenie danych o obiekcie automatyki i bieżących działaniach;

Ocena jakości funkcjonowania obiektu i rodzajów prowadzonych czynności, identyfikacja problemów, które można rozwiązać za pomocą automatyzacji;

Ocena (techniczna, ekonomiczna, społeczna itp.) wykonalności utworzenia AU.

2. Na etapie 1.2 „Opracowanie wymagań użytkownika dla AU” wykonaj:

Przygotowanie danych wstępnych do tworzenia wymagań dla AU (charakterystyka obiektu automatyki, opis wymagań dla systemu, limity dopuszczalnych kosztów rozwoju, uruchomienia i eksploatacji, oczekiwany efekt od systemu, warunki tworzenia i obsługi systemu);

Formułowanie i realizacja wymagań użytkowników dla AU.

3. Na etapie 1.3 „Złożenie sprawozdania z wykonanych prac i wniosku o opracowanie AU (zadanie taktyczno-techniczne)” sporządzane jest sprawozdanie z wykonanych prac na tym etapie oraz wniosek o opracowanie AU (przydział taktyczno-techniczny) lub inny dokument zastępujący go o podobnej treści.

4. Na etapach 2.1 „Badanie obiektu” i 2.2 „Przeprowadzenie niezbędnych prac badawczych” organizacja deweloperska przeprowadza szczegółowe badanie obiektu automatyki oraz niezbędne prace badawcze (B+R) związane ze znalezieniem sposobów i oceną możliwości wdrożenia użytkownika wymagań, sporządzanie i zatwierdzanie raportów z badań.

5. Na etapie 2.3 „Opracowanie wariantów koncepcji AU i wybór wariantu koncepcji AU odpowiadającego wymaganiom użytkownika”, w przypadku ogólnym warianty alternatywne dla koncepcji tworzonej AU opracowywane są plany ich realizacji; ocena niezbędnych zasobów do ich realizacji i eksploatacji; ocena zalet i wad każdej opcji; porównanie wymagań użytkowników i cech proponowanego systemu oraz wybór najlepszej opcji; określenie trybu oceny jakości i warunków odbioru systemu; ocena efektów uzyskanych z systemu.

6. Na etapie 2.4 „Sformułowanie raportu z wykonanych prac” sporządzany jest i sporządzany jest raport zawierający opis prac wykonanych na etapie, opis i uzasadnienie proponowanej wersji koncepcji systemu.

7. Na etapie 3.1 „Opracowanie i zatwierdzenie specyfikacji istotnych warunków zamówienia na budowę EJ”, opracowanie, wykonanie, koordynacja i zatwierdzenie specyfikacji istotnych warunków zamówienia dla EJ oraz w razie potrzeby specyfikacji istotnych warunków zamówienia dla części realizowane są elektrownie jądrowe.

8. Na etapie 4.1 „Opracowanie wstępnych rozwiązań projektowych systemu i jego części” określa się: funkcje AU; funkcje podsystemów, ich cele i efekty; kompozycja kompleksów zadań i zadań indywidualnych; pojęcia baza informacji, jego powiększona struktura; funkcje systemu zarządzania bazą danych; skład systemu komputerowego; funkcje i parametry głównych narzędzi programowych.

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 funkcjonalnej i algorytmicznej systemu, funkcji personelu i struktury organizacyjnej, strukturę środków technicznych, algorytmy rozwiązywania problemów i używane języki, organizację i obsługę bazy informacyjnej, system klasyfikacji i kodowania informacji, oprogramowanie.

10. Na etapach 4.2 i 5.2 „Opracowanie dokumentacji dla EJ i jej części” następuje opracowanie, wykonanie, koordynacja i zatwierdzenie dokumentacji w ilości niezbędnej do opisania pełnego zestawu przyjętych decyzji projektowych i wystarczającej do dalszych prac w sprawie powstania elektrowni jądrowej. Rodzaje dokumentów - zgodnie z GOST 34.201.

11. Na etapie 5.3 „Opracowanie i wykonanie dokumentacji na dostawę produktów do wykonania EJ i (lub) wymagań technicznych (specyfikacji technicznych) na ich zabudowę” następuje: przygotowanie i wykonanie dokumentacji na dostawę produktów za ukończenie elektrowni jądrowej; określenie wymagań technicznych i przygotowanie specyfikacji technicznych dla rozwoju produktów, które nie są produkowane seryjnie.

12. Na etapie 5.4 „Opracowanie zadań projektowych w sąsiednich częściach projektu obiektu automatyki” opracowują, opracowują, uzgadniają i zatwierdzają zadania projektowe w sąsiednich częściach projektu obiektu automatyki dla robót budowlanych, elektrycznych, sanitarnych i innych prac przygotowawczych związanych do powstania AS.

13. Na etapie 6.1 „Opracowanie dokumentacji roboczej systemu i jego części” opracowują dokumentację roboczą zawierającą wszystkie niezbędne i wystarczające informacje do zapewnienia realizacji prac związanych z uruchomieniem i eksploatacją EJ oraz do utrzymania poziom charakterystyki eksploatacyjnej (jakości) systemu zgodnie z przyjętymi decyzjami projektowymi, jego wykonanie, koordynacja i akceptacja. Rodzaje dokumentów - zgodnie z GOST 34.201.

14. Na etapie 6.2 „Opracowanie lub adaptacja programów” opracowywane są programy i oprogramowanie systemu, wybór, adaptacja i (lub) oprawa zakupionego oprogramowania, opracowanie dokumentacji oprogramowania zgodnie z GOST 19.101.

15. Na etapie 7.1 „Przygotowanie obiektu automatyki do oddania AU” prowadzone są prace związane z przygotowaniem organizacyjnym obiektu automatyki do oddania AU, w tym: realizacja decyzji projektowych dotyczących struktury organizacyjnej UA; dostarczanie jednostkom obiektu kontrolnego materiałów instruktażowych i metodycznych; wprowadzenie klasyfikatorów informacji.

16. Na etapie 7.2 „Szkolenie personelu” szkoli się personel i sprawdza jego zdolność do zapewnienia funkcjonowania EJ.

17. Na etapie „Pakowania AU z dostarczonymi wyrobami” należy zapewnić odbiór elementów produkcji seryjnej i jednostkowej, materiałów oraz wyrobów montażowych. Przeprowadź kontrolę jakości danych wejściowych.

18. W etapie 7.4 „Roboty budowlano-montażowe” prowadzona jest: budowa specjalistycznych budynków (pomieszczeń) przeznaczonych na umieszczenie zaplecza technicznego i personelu EJ; budowa kanałów kablowych; wykonanie robót w zakresie instalacji środków technicznych i linii komunikacyjnych; testowanie zainstalowanych środków technicznych; dostawa środków technicznych do uruchomienia.

19. Na etapie 7.5 „Uruchomienie” przeprowadzić offline regulację sprzętu i oprogramowania, załadować informacje do bazy danych i sprawdzić system jej utrzymania; kompleksowa regulacja wszystkich środków systemu.

20. Na etapie 7.6 „Przeprowadzenie badań wstępnych” wykonać:

Testowanie AU pod kątem wydajności i zgodności z zakresem zadań zgodnie z programem i metodologią testów wstępnych;

Rozwiązywanie problemów i wprowadzanie zmian w dokumentacji dla EJ, w tym dokumentacji eksploatacyjnej zgodnie z protokołem z badań;

Rejestracja aktu przyjęcia UA do eksploatacji próbnej.

21. Na etapie 7.7 „Przeprowadzenie ruchu próbnego” przeprowadza się: rozruch próbny EJ; analiza wyników próbnej eksploatacji elektrowni jądrowej; finalizacja (jeśli to konieczne) oprogramowania AS; dodatkowe dostosowanie (w razie potrzeby) środków technicznych UA; rejestracja zaświadczenia o zakończeniu eksploatacji próbnej.

22. Na etapie 7.8 „Przeprowadzenie testów akceptacyjnych” wykonaj:

Testy na zgodność z SIWZ zgodnie z programem i metodologią testów akceptacyjnych;

Analiza wyników testów AU i eliminacja niedociągnięć zidentyfikowanych podczas testów;

Rejestracja aktu przyjęcia EJ do stałej eksploatacji.

23. Na etapie 8.1 „Wykonywanie prac zgodnie ze zobowiązaniami gwarancyjnymi” prowadzone są prace mające na celu wyeliminowanie uchybień stwierdzonych podczas eksploatacji EJ w ustalonych okresach gwarancyjnych, dokonanie niezbędnych zmian w dokumentacji EJ.

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

Analiza funkcjonowania systemu;

Identyfikacja odchyleń rzeczywistych charakterystyk eksploatacyjnych EJ od wartości projektowych;

Ustalenie przyczyn tych odchyleń;

Eliminacja stwierdzonych braków i zapewnienie stabilności charakterystyk eksploatacyjnych EJ;

Dokonanie niezbędnych zmian w dokumentacji dla AU.

ZAŁĄCZNIK 2 (informacyjny). WYKAZ ORGANIZACJI UCZESTNICZĄCYCH W TWORZENIU UA

ZAŁĄCZNIK 2
Odniesienie

1. Organizacja klienta (użytkownik), dla której tworzona jest EJ i która zapewnia finansowanie, odbiór prac i eksploatację EJ oraz wdrożenie prace indywidualne w sprawie utworzenia AS;

2. Organizacja-programista, który prowadzi prace nad stworzeniem AU, dostarczając klientowi zestaw usług naukowych i technicznych na różnych etapach i etapach tworzenia, a także opracowując i dostarczając różne oprogramowanie i sprzęt AU;

3. Organizacja-dostawca, który produkuje i dostarcza oprogramowanie i sprzęt na zamówienie dewelopera lub klienta;

4. Organizacja-generalny projektant obiektu automatyki;

5. Organizacje-projektanci różnych części projektu obiektu automatyki do prac budowlanych, elektrycznych, sanitarnych i innych prac przygotowawczych związanych z utworzeniem AU;

6. Budowa, instalacja, regulacja i inne organizacje.

Uwagi:

1. W zależności od warunków utworzenia AU możliwe są różne kombinacje funkcji klienta, programisty, dostawcy i innych organizacji zaangażowanych w tworzenie AU.

2. Etapy i etapy ich prac nad utworzeniem UA określa się na podstawie niniejszego standardu.

Tekst elektroniczny dokumentu
sporządzony przez Kodeks JSC i zweryfikowany pod kątem:
oficjalna publikacja
M.: Standartinform, 2009

Dlaczego w zasadzie są potrzebne w projekcie?

Okazuje się, że GOST pomagają samemu projektantowi.

Głównym problemem w projektowaniu jest brak samego projektu. Są jakieś fragmenty myśli, pragnień, ale bez układania ich w jakiś spójny obraz. Dotyczy to zarówno początkujących, jak i administratorzy systemu i początkujących inżynierów systemowych. Jest pewna spontaniczność myślenia. Nawiasem mówiąc, jest to również charakterystyczne dla wielu klientów. Są jednak w nieco lepszej sytuacji niż wykonawcy.

Powstaje interesujące pytanie: kto potrzebuje tych wszystkich wyjaśnień, specyfikacji technicznych itp.? I tu otrzymujemy ciekawą odpowiedź: 85% dokumentacji jest niezbędne dla wykonawcy. Pozostałe 15% jest potrzebne klientowi do ogólnego zrozumienia tego, co się dzieje. Ale wykonawca musi jasno określić zarówno granice projektu, jak i oznaki jego realizacji. Wykonawca musi umieć obronić się przed chaotycznym myśleniem klienta.

Przejdźmy więc do GOST dewelopera. Mamy dwa główne: seria GOST 34. i seria GOST 19. Seria 34 odnosi się do rozwoju systemów zautomatyzowanych, a 19 do rozwoju oprogramowania.
Porozmawiamy o serii GOST 34.

W 34. serii jest wiele różnych GOST. Nas zainteresuje tylko kilka z nich. Mianowicie:

1. GOST 34.003-90 Technologia informacyjna. Zestaw norm dla systemów zautomatyzowanych. Warunki i definicje
2. GOST 34.601-90 Technologia informacyjna. Zestaw norm dla systemów zautomatyzowanych. Systemy automatyczne. Etapy tworzenia
3. GOST 34.602-89 Technologia informacyjna. Zestaw norm dla systemów zautomatyzowanych. Specyfikacja istotnych warunków zamówienia na stworzenie zautomatyzowanego systemu
4. GOST 34.603-92 Technologia informacyjna. Rodzaje testowania systemów automatycznych
5. GOST 34.201-89 Technologia informacyjna. Zestaw norm dla systemów zautomatyzowanych. Rodzaje, kompletność i oznaczenie dokumentów przy tworzeniu systemów automatycznych
6. RD 50-34.698-90 Systemy automatyczne. Wymagania dotyczące treści dokumentu.

GOST są nieco podobne w swojej hierarchicznej strukturze do katalogu. Na takich jak np Active Directory. Jest prawdopodobne, że jeśli piszesz dokumentację ściśle według GOST, odsyłacze pozwolą ci zapoznać się z ogromną liczbą dokumentów. Ale to, co najważniejsze w GOST, to jasny model „od ogółu do szczegółu”. Zaczynając od ogólnych zwrotów, przejdziemy do ostatniego RJ45 w systemie.

A teraz bardziej szczegółowo. Główny GOST, wokół którego tzw. taniec to GOST 34.601-90 (Etapy tworzenia). Przyjrzyjmy się bliżej temu dokumentowi.

To jest struktura, w której się spotykamy ten dokument. Co w tym takiego wspaniałego? Niezwykłą rzeczą jest to, że widzimy prawie pełny cykl życia zautomatyzowanego systemu. Dlaczego prawie? Bo nie ma takiego etapu jak likwidacja i utylizacja. Ale tak naprawdę tego nie potrzebujemy. Jak dotąd istniejące etapy są więcej niż wystarczające. Ponadto etap recyklingu jest rozważany w jednym z pozostałych GOST, ale wykracza to poza zakres tego artykułu.

Jak powiedziałem powyżej, GOST zawierają odsyłacze. Aby pójść dalej w naszym rozumowaniu, przyjrzymy się GOST 34.003-90 (Terminy i definicje). Interesuje się definicją systemu zautomatyzowanego. Jest to ważne, ponieważ musimy jeszcze mieć pomysł na to, co będziemy tworzyć.

GOST 34.003-90 w definicji zautomatyzowanego systemu mówi nam, co następuje: zautomatyzowany system; AS: System składający się z personelu i zestawu środków automatyzujących jego działania, wdrażający technologia informacyjna wykonywanie ustalonych funkcji. Te. Innymi słowy, AS składa się z

1. Personel
2. złożone środki
3. niektóre czynności mają być zautomatyzowane.

Sprawdzimy również w GOST 34.003-90

1. zestaw narzędzi do automatyzacji zautomatyzowanego systemu; KSA AS: Całość wszystkich składników AS, z wyjątkiem ludzi
2. użytkownik zautomatyzowanego systemu; Użytkownik AC: Osoba uczestnicząca w funkcjonowaniu AS lub korzystająca z efektów jego funkcjonowania
3. personel obsługujący zautomatyzowany system; personelu obsługującego zakład
4. element zautomatyzowanego systemu; komponent AC: Część AS, przydzielona zgodnie z określoną cechą lub zestawem cech i rozpatrywana jako całość

Więc co dostajemy? I okazuje się, że czuliśmy pod stopami jakiś fundament, na którym będziemy polegać. Wiemy, z czego składa się zautomatyzowany system i wyjaśniliśmy, że istnieją dwa rodzaje personelu: użytkownik i personel operacyjny. I logicznie wnioskujemy, że składową AS, wybraną według pewnego atrybutu, będzie ts. „sprzęt” i „oprogramowanie”, jeśli po prostu. A całość programu + sprzętu będzie zestawem narzędzi automatyzacji dla AU.

Jeśli więc klient powie np. „I zainstaluj dla mnie Exchange”, to nie będzie to AC z jednego prostego powodu: przynajmniej w takim zadaniu nie ma zautomatyzowanej czynności. A może klient wcale nie potrzebuje Exchange. A może wcale nie potrzebuje wymiany. A to oznacza, że ​​wymagany jest przegląd obiektu automatyki. Oznacza to, że rozpoczyna się pierwszy etap GOST 34.601-90 (Etapy tworzenia). „Tworzenie wymagań dla UA”

Na tym etapie GOST wymaga od nas wykonania kilku kroków. Jeśli przełożymy to na ludzki język, to tutaj musimy ustalić, czy w ogóle konieczne jest opracowanie czegokolwiek. Czy to właściwe różne punkty widzenia. Ogólnie oceń potrzebę podjęcia pracy. Efektem pracy na tym etapie jest raport, który rejestruje wynik.

Po ustaleniu z klientem, że istnieją wystarczające podstawy do rozwoju, możemy przejść do kolejnego etapu „Opracowanie koncepcji AC”.

W koncepcji musimy przestudiować obiekt, w którym jest on wymagany do wdrożenia. Jeśli w pierwszym etapie szukaliśmy ogólnego powodu do stworzenia AS (opierając się tylko na celach biznesowych, GOST został po prostu napisany, gdy takie słowa nie zostały użyte), to w drugim etapie musimy znaleźć możliwe opcje, które spełniają wymagań klienta. Na przykład, jeśli klient chce system pocztowy, to można to zaimplementować zarówno na Exchange, jak i na Postfixie lub na czymkolwiek innym. Ze swoimi plusami, minusami i możliwościami rozwoju. Przeprowadzane są ogólne oględziny obiektu i wstępne oszacowanie kosztów robocizny. My, jako wykonawcy, również szukamy najlepszej opcji dla siebie.
Po dojściu do pewnego konsensusu z klientem co do tego, który konkretny wariant rozwiązania najbardziej mu odpowiada w ogólnych zarysach, przechodzimy do, nie boję się tego słowa, najważniejszego punktu projektu „WZ”

Zakres wymagań i obowiązków, jeśli spojrzeć na definicję GOST 34.602-89, jest głównym dokumentem określającym wymagania i procedurę tworzenia (rozwoju lub modernizacji - dalszego tworzenia) zautomatyzowanego systemu, zgodnie z którym rozwój AU jest wykonywana i jej akceptacja przy uruchomieniu.

TK jest tak ważnym dokumentem, że jest mu poświęcony osobisty GOST. Teraz nie będziemy się nad tym szczegółowo rozwodzić. Zaznaczę tylko, że do prawidłowego sformułowania specyfikacji technicznych konieczne jest ukończenie etapów GOST 34.601-90 „Formowanie wymagań dla AU” i „Opracowanie koncepcji AU”. Poprawność i poprawność tworzenia TK zależy od jakości tych etapów.

Data wprowadzenia od 01.07.1987r

Niniejsza norma ma zastosowanie do systemów automatycznych (AS) stosowanych w różne rodzaje działalność (badania, projektowanie, zarządzanie), w tym ich kombinacje (badania - projektowanie - zarządzanie, projektowanie - zarządzanie) tworzone w organizacjach, stowarzyszeniach i przedsiębiorstwach (dalej - organizacje).

Norma określa etapy i etapy tworzenia i rozwoju AU oraz główne wyniki pracy na każdym etapie.

Norma nie ma zastosowania do procedury opracowywania komponentów stosowanych w AU.

Procedurę rozwoju dostarczonych kompleksów urządzeń automatyki, sprzętu, oprogramowania itp. określają standardy systemu rozwoju i dostaw produktów i urządzeń do produkcji, który obowiązuje w dziale klienta EJ.

Dodatek referencyjny zawiera wyjaśnienia i niektóre terminy użyte w normie.

1. POSTANOWIENIA OGÓLNE

1.1. Stworzenie (rozwój) AS to uporządkowany w czasie, wzajemnie powiązany, zespolony w etapy i etapy zespół prac, których realizacja jest konieczna i wystarczająca do stworzenia AS spełniającego określone wymagania.

1.2. Skład, treść i procedura wykonywania pracy na etapach i etapach określonych w niniejszej normie są określone w dokumentacji regulacyjnej i technicznej dotyczącej utworzenia elektrowni jądrowej odpowiedniego typu.

2. ETAPY I ETAPY TWORZENIA SYSTEMÓW AUTOMATYCZNYCH

2.1. Etapy i etapy pracy podano w tabeli.

* Etapy mogą być realizowane na etapach poprzednich w zależności od konkretnych warunków zabudowy.

2.2. Skład, kolejność i czas etapów i etapów prac wykonywanych podczas tworzenia (rozwoju) AU są określone w zakresie wymagań dotyczących tworzenia (rozwoju) systemu spośród etapów i etapów podanych w tabeli.

2.3. Wykorzystanie zamówionego AS w podobnych obiektach odbywa się za pomocą gotowych rozwiązań projektowych opracowanego systemu i produkowanych seryjnie komponentów (zespołów urządzeń automatyki, oprogramowania, sprzętu itp.) Produktów.

Decyzję o możliwości wykorzystania AU podejmuje komisja podczas testów akceptacyjnych systemu.

2.4. Podczas tworzenia (rozwoju) AU obowiązkowymi etapami są: „Specyfikacja istotnych warunków zamówienia”, „Projekt techniczny”, „Dokumentacja szczegółowa” i „Woda do eksploatacji”.

Dla proste systemy i systemy opracowane w oparciu o standardowe rozwiązania projektowe, łączą etapy „Projektu Technicznego” i „Dokumentacji Szczegółowej” w jeden.

2.5. Obowiązkowe kroki w tworzeniu AU to: 1.2; 2,3; 4,1-4,5; 4,7; 4,9 - 4,11; 5.1; 5,2; 5,5; 7.1; 7,3 - 7,5; 7,6 i 7,8.

2.6. Dopuszcza się prowadzenie prac badawczych (etap 2.1) na etapie „Badania i uzasadnienie utworzenia AU” oraz w razie potrzeby na innych etapach.

3. WYNIKI WYKONYWANIA PRAC W PODZIALE NA ETAPY

3.1. Wynikiem etapu „Badania i uzasadnienie utworzenia AU” jest raport naukowo-techniczny, zadanie taktyczno-techniczne, studium wykonalności lub wniosek o utworzenie AU.

3.2. Efektem realizacji etapu „SUM” jest SIWZ na utworzenie AS.

3.3. Wynikiem etapu „Szkic projektu” jest projekt koncepcyjny.

3.4. Efektem prac na etapie „Projekt techniczny” jest projekt techniczny.

3.5. Efektem prac na etapie „Dokumentacja robocza” jest komplet dokumentacji roboczej dla EJ.

3.6. Efektem prac na etapie „Produkcji elementów nieseryjnych KSA” są elementy KSA, które przeszły testy w przewidziany sposób.

3.7. Efektem prac na etapie „Rozruchu” jest przyjęcie EJ do komercyjnej eksploatacji.

3.9. Rozbudowa (modernizacja) lub likwidacja systemu odbywa się na podstawie decyzji podejmowanych na podstawie wyników analizy eksploatacji.

APLIKACJA

TERMINY UŻYTE W STANDARDZIE I ICH OBJAŚNIENIA

Proces tworzenia AS to zbiór uporządkowanych w czasie, wzajemnie powiązanych, połączonych etapami i etapami prac, których realizacja jest konieczna i wystarczająca do stworzenia AS spełniającego określone wymagania.

Etapy i etapy tworzenia AS wyróżnia się jako części procesu tworzenia ze względu na racjonalne planowanie i organizację pracy, kończącej się określonym rezultatem.

Prace nad rozwojem AU prowadzone są zgodnie z etapami i etapami stosowanymi do tworzenia AU.

Skład i zasady wykonywania pracy na etapach i etapach określonych w niniejszym standardzie są określone w odpowiedniej dokumentacji organizacji zaangażowanych w tworzenie określonych typów elektrowni jądrowych.

Etapy i etapy pracy

1. Tworzenie wymagań dla AU

1.1. Inspekcja obiektu i uzasadnienie potrzeby utworzenia AU.

1.2. Tworzenie wymagań użytkownika dla AU.

1.3. Rejestracja raportu z wykonanej pracy i wniosek o opracowanie AU (specyfikacje taktyczne i techniczne)

2. Rozwój koncepcji AS.

2.1. Studium obiektu.

2.2. Przeprowadzenie niezbędnych prac badawczych.

2.3. Opracowanie wariantów koncepcji AU spełniających wymagania użytkownika.

2.4. Sporządzenie raportu z wykonanej pracy.

3. Specyfikacja istotnych warunków zamówienia.

Opracowanie i zatwierdzenie zakresu zadań dla utworzenia UA.

4. Szkic projektu.

4.1. Opracowanie wstępnych rozwiązań projektowych systemu i jego części.

4.2. Opracowanie dokumentacji dla AU i jego części.

5. Projekt techniczny.

5.1. Opracowanie rozwiązań konstrukcyjnych systemu i jego części.

5.2. Opracowanie dokumentacji dla AU i jego części.

5.3. Opracowanie i wykonanie dokumentacji na dostawę produktów do pozyskiwania elektrowni jądrowych i (lub) wymagań technicznych (specyfikacji technicznych) dla ich rozwoju.

5.4. Opracowanie zadań projektowych w sąsiednich częściach projektu obiektu automatyki.

6. Dokumentacja robocza.

6.1. Opracowanie dokumentacji roboczej systemu i jego części.

6.2. Rozwój lub adaptacja programów.

7. Uruchomienie.

7.1. Przygotowanie obiektu automatyki do uruchomienia AU.

7.2. Szkolenie personelu.

7.3. Uzupełnienie AU o dostarczone produkty (oprogramowanie i sprzęt, oprogramowanie i systemy sprzętowe, produkty informacyjne).

7.4. Roboty budowlane i instalacyjne.

7,5. Prace rozruchowe.

7.6. Przeprowadzanie wstępnych testów.

7.7. Przeprowadzenie operacji próbnej.

7.8. Przeprowadzanie testów akceptacyjnych.

8. Towarzyszący mówcy

8.1. Wykonywanie prac zgodnie ze zobowiązaniami gwarancyjnymi.

8.2. Serwis pogwarancyjny.

GOST 34.602-89 „Warunki odniesienia dla stworzenia zautomatyzowanego systemu”

1. POSTANOWIENIA OGÓLNE

1.1. SIWZ dla EJ jest głównym dokumentem określającym wymagania i procedurę tworzenia (rozwoju lub modernizacji - dalszej budowy) systemu automatycznego, zgodnie z którym przeprowadzana jest rozbudowa EJ i jej odbiór przy oddaniu do eksploatacji.

1.2. Specyfikacje dla elektrowni jądrowych opracowywane są dla systemu jako całości, zaprojektowanego do pracy samodzielnej lub jako część innego systemu.

1.3. Wymagania dla AU w zakresie ustalonym przez tę normę można uwzględnić w zadaniu dotyczącym zaprojektowania nowo utworzonego obiektu automatyki. W tym przypadku nie są opracowywane specyfikacje techniczne dla elektrowni jądrowych.

1.4. Wymagania zawarte w TOR dla elektrowni jądrowych muszą odpowiadać obecnemu poziomowi rozwoju nauki i techniki i nie mogą być gorsze od podobnych wymagań dla najlepszych nowoczesnych analogów krajowych i zagranicznych. Wymagania określone w SIWZ dla elektrowni jądrowych nie powinny ograniczać twórcy systemu w poszukiwaniu i wdrażaniu najefektywniejszych rozwiązań technicznych, wykonalnościowych i innych.

1.5. Specyfikacje dla elektrowni jądrowych opracowywane są na podstawie danych wstępnych, w tym zawartych w dokumentacji końcowej etapu „Badania i uzasadnienie powstania elektrowni jądrowych”, ustalonej przez GOST 24.601.

1.6. TOR dla elektrowni jądrowych zawiera tylko te wymagania, które uzupełniają wymagania dla systemów tego typu (ACS, CAD, ASNI itp.) zawarte w aktualnej NTD i są określone specyfiką konkretnego obiektu, dla którego system jest przeznaczony tworzony.

1.7. Zmiany w TOR w EJ są formalizowane aneksem lub protokołem podpisanym przez klienta i dewelopera. Aneks lub określony protokół stanowi integralną część SIWZ dla EJ. Na stronie tytułowej TK na AC powinien znajdować się wpis „Ważny od ...”.

2. SKŁAD I ZAWARTOŚĆ

2.1. SIWZ dla elektrowni jądrowej zawiera następujące sekcje, które można podzielić na podrozdziały:

2) cel i cele powstania (rozwoju) systemu;

3) charakterystyki obiektów automatyki;

4) wymagania systemowe;

5) skład i treść prac nad stworzeniem systemu;

6) tryb kontroli i odbioru systemu;

7) wymagania dotyczące składu i treści prac przygotowujących obiekt automatyki do oddania systemu do eksploatacji;

8) wymagania dotyczące dokumentacji;

9) źródła rozwoju.

Wnioski mogą być uwzględnione w TOR dla UA.

GOST 34.603-92 „Rodzaje testów”

1. POSTANOWIENIA OGÓLNE

1.1. Testy elektrowni jądrowej przeprowadzane są na etapie „rozruchu” zgodnie z GOST 34.601 w celu sprawdzenia zgodności utworzonej elektrowni jądrowej z wymaganiami zakresu zadań i obowiązków (TOR).

1.2. Testowanie EJ to proces sprawdzania działania określonych funkcji systemu, określania i weryfikacji zgodności z wymaganiami TOR w zakresie charakterystyki ilościowej i (lub) jakościowej systemu, identyfikacji i eliminacji niedociągnięć w działaniu systemu , w opracowanej dokumentacji.

1.3. W przypadku UA ustanowiono następujące główne rodzaje testów:

a) wstępny;

1) autonomiczny;

2) złożony.

b) działanie próbne;

Eksploatacja próbna odbywa się zgodnie z programem, który wskazuje:

1) warunki i tryb funkcjonowania części UA i UA jako całości;

2) czas trwania ruchu próbnego, wystarczający do sprawdzenia poprawności funkcjonowania EJ przy wykonywaniu każdej funkcji systemu oraz gotowości personelu do pracy w warunkach pracy EJ;

3) tryb usuwania usterek stwierdzonych podczas eksploatacji próbnej.

c) akceptacja.

Testy akceptacyjne przeprowadzane są zgodnie z programem, który wskazuje:

1) wykaz obiektów przeznaczonych do testowania w systemie oraz wykaz wymagań, jakie muszą spełniać obiekty (z odniesieniem do punktów SIWZ);

2) kryteria odbioru systemu i jego części;

3) warunki i terminy przeprowadzania badań;

4) środki do badań;

5) nazwiska osób odpowiedzialnych za przeprowadzenie badań;

6) metodologię badań i przetwarzanie ich wyników;

7) wykaz dokumentacji do sporządzenia.

http://www.franklin-grant.ru/ru/technologies/gost.asp

Cechy organizacji pozarządowej. Charakterystyka obiektów kontrolnych.

Struktura organizacji pozarządowej. Poziomy i systemy zarządzania organizacjami pozarządowymi.

Cechy BT w NGO:

1) Rozmieszczenie terytorialne obiektów ropy i gazu, VT i AS.

2) Ciągły lub dyskretno-ciągły charakter procesów technologicznych.

3) Trudne klimatyczne warunki eksploatacji i duże zagrożenie pożarowe.

4) Nisko wykwalifikowany personel serwisowy.

5) Przedsiębiorstwa przemysłu są miastotwórcze.

Schemat połączenia kompleksów technologicznych zakładów wydobywczych ropy i gazu został powiększony:

Etapy rozwoju. Sekwencja przejść metasystemu:

Lata 70. - scentralizowane systemy gromadzenia i przetwarzania informacji oparte na komputerze ES: KIVTs \ RIVTs.

Lata 80. - technologia mikroprocesorowa, pojawiają się nowe narzędzia (zdecentralizowane): SM-computer, TECHNIK, MicroDat.

lata 90 - system klastrowy, zestaw względnie autonomicznych podsystemów: PC.

2000 - technologie klient-serwer, technologie sztucznej inteligencji, zagraniczne rozwiązania techniczne.

Obecnie organizacje pozarządowe są na wysokim poziomie rozwoju.

Autorskie koncepcje i rozwiązania automatyzacji wydobycia ropy i gazu:

1) ERP (Enterprise Resource Planning) - zautomatyzowany system kontroli, AS zarządzania zasobami przedsiębiorstwa.

2) EAM (Enterprise Asset Management) - AS do zarządzania zdolnościami produkcyjnymi i środkami finansowymi.

3) MES (Manufacturing Execution System) – zautomatyzowane systemy sterowania, systemy operacyjnego zarządzania produkcją.

4) SCADA - APCS, AS do sterowania procesami.

PLC - programowe sterowniki logiczne.

DCS - rozproszone systemy sterowania.

AS jest realizowany jako sekwencja informacji powiązane funkcje, zadania lub procedury wykonywane w trybie zautomatyzowanym (interaktywnym) lub automatycznym.

Zautomatyzowane kompleksy technologiczne- zestaw narzędzi technologicznych i programowych niezbędnych dla określonego rodzaju produkcji i procesów produkcyjnych.

4) opracowanie optymalnych reżimów technologicznych;

5) obliczenie niezbędnych zasobów materialnych i ich optymalnego rozmieszczenia - wyposażenie;

6) zestawienie maksymalnego bilansu i analizy kosztów jednostkowych;

7) analiza przestojów urządzeń technologicznych i rozliczanie strat;

8) zautomatyzowane przetwarzanie wyniki badań i informacje technologiczne;

9) zarządzanie konserwacją i naprawą urządzeń technologicznych.

Na najwyższym poziomie rozwiązywanie problemów ma na celu wspomaganie podejmowania decyzji przez specjalistów w zmieniających się warunkach przedsiębiorstwa.

Rozwiązanie tych problemów ma na celu wspomaganie podejmowania decyzji w przedsiębiorstwie (szczebel średni).

Funkcjonalność hali produkcyjnej:

1) zbieranie informacji przez systemy automatyki obiektów technologicznych;

2) tworzenie i utrzymywanie bazy danych;

3) tworzenie i przekazywanie informacji na poziomie przedsiębiorstwa;

4) kontrola stanu wyposażenia trybów technologicznych;

5) operacyjne obliczenia skuteczności imprezy;

6) diagnostykę działania urządzeń technologicznych i technicznych środków automatyki;

7) prowadzenie dokumentacji sprawozdawczej i planistycznej.

Rozwiązanie tych problemów ma na celu realizację decyzji podjętych w zmieniających się warunkach pracy sklepów przedsiębiorstwa.

Wymagania dla ACS na różnych szczeblach organizacji pozarządowych. (rysunek)

Poziom obiektu technologicznego:

(Niższy poziom)

1) zbieranie informacji z czujników i systemów automatyki zgodnie z przepisami;

2) automatyczne przetwarzanie i przechowywanie informacji pierwotnych;

3) automatyczne sterowanie i regulacja obiektów technicznych (ustawianie kart);

4) dialog z operatorem-technologiem;

5) zapewnienie kontroli parametrów bezpieczeństwa.

Podstawowe zasady budowania AS na różnych poziomach przedsiębiorstwa:

1) Niezmienność wykonywania funkcji na każdym poziomie sterowania w odniesieniu do liczby i typów obiektów technologicznych: system jest konfigurowalny dla konkretnych obiektów otwartych i uzupełniany o nowe f-mi. Drzewo typów obiektów => drzewo określonych obiektów.

2) Intelektualizacja tych i programów wplecionych przez automatyzację f-tego personelu.

3) Standaryzacja, gwarantowana kompatybilność aparatury i programów, aw efekcie obniżenie kosztów ich eksploatacji.

4) Architektura zespołu tych środków powinna zapewniać realizację różnych konfiguracji systemu sterowanego promieniowymi, pierścieniowymi i mieszanymi kanałami łączności, m.in. drogą kablową i radiową.

Rodzaje zabezpieczeń AS. Problemy, modele i sposoby integracji zautomatyzowanych systemów kontroli w organizacjach pozarządowych

W ogólnym przypadku zautomatyzowane systemy składają się z kompleksów programowych i sprzętowych (PTC), kompleksów programowych i metodologicznych (PMC) oraz komponentów technicznych. Wsparcie w zakresie oprogramowania i informacji.

AS to zestaw wzajemnie uzgodnionych komponentów i kompleksów oprogramowania, wsparcia technicznego i informacyjnego, opracowanych, wyprodukowanych i dostarczonych jako produkty do celów przemysłowych. Wspólne funkcjonowanie i interakcja kompleksów odbywa się w oparciu o sieci komputerowe.

Oprogramowanie AS - zestaw programów na nośnikach informacyjnych z dokumentacją programu zgodnie z GOST 19.101.

Pomoc techniczna AS - zestaw środków do realizacji działań kontrolnych, środków do odbioru, wprowadzania, przygotowywania, konwersji, przetwarzania, przechowywania rejestracji, wyprowadzania, wyświetlania, wykorzystywania i przesyłania danych z dokumentacją projektową zgodnie z GOST 2.102 i dokumentacją operacyjną zgodnie z GOST 2.601 .

AS Information Support to zbiór zorientowanych systemowo danych opisujących słownik podstawowych opisów przyjętych w systemie (klasyfikatory, modele standardowe, elementy automatyki, formaty dokumentacji) oraz zaktualizowanych danych o stanie modelu informacyjnego obiektów automatyki (obiektu sterowania , projektowanie) na wszystkich etapach cyklu życia.

Wsparcie organizacyjno-metodyczne AS – komplet dokumentów określających strukturę organizacyjną obiektu i systemu automatyki, działania w warunkach funkcjonowania systemu, formy prezentacji wyników działań.

Matematyczne wsparcie AS – zestaw metod matematycznych modeli i algorytmów przetwarzania informacji wykorzystywanych w działaniu systemu.

Wsparcie językowe - zestaw narzędzi językowych do budowania i łączenia jednostek informacyjnych KSA.