تعریف بازو GOST. عملیات آزمایشی سیستم کنترل خودکار. الزامات تست برای سیستم های کنترل فرآیند خودکار

M. Ostrogorsky, 2008

برای اعمال موفقیت آمیز GOST 34، لازم است بدانیم که چگونه از دیدگاه این مجموعه استانداردها، یک سیستم خودکار تنظیم می شود. در غیر این صورت، جز فهرست بلندی از اسناد با نام های مرموز، چیزی در مهمانان نخواهیم دید و الزامات محتوای آنها بار دیگر ما را متقاعد می کند که در بسیاری از حکمت ها غم و اندوه زیادی وجود دارد. بنابراین، قبل از بحث در مورد خود اسناد، باید درک کنیم که موضوع مستندسازی چیست.

سیستم خودکار، توابع و وظایف آن

تعریف سیستم خودکار

GOST 34.003-90 شامل تعریف زیر از یک سیستم خودکار است: سیستمی متشکل از پرسنل و مجموعه ای از وسایل برای خودکارسازی فعالیت های آنها که فناوری اطلاعات را برای انجام وظایف تعیین شده پیاده سازی می کند. این تعریف در عمل به چه معناست؟ شما فقط با خواندن سایر تعاریف این استاندارد و مقایسه آنها با یکدیگر می توانید متوجه این موضوع شوید. کاری که الان قرار است انجام دهیم.

اهداف فعالیت

یک سیستم خودکار فقط در جایی می تواند وجود داشته باشد که پرسنلی درگیر یک فعالیت خاص باشند. معمولا، می آیددر مورد فعالیت هایی که نتایج آنها صرف نظر از ابزار مورد استفاده برای کسی مفید است. مثلاً من برای تهیه بلیت به گیشه مراجعه می کنم و اگر صندوقدار آن را با یک خودکار روی سربرگ برایم بنویسد تا من را با آن وارد سالن کنند برایم خوب است. صندوقدار، به طور کلی، به نحوه تهیه بلیط نیز اهمیتی نمی دهد. هر روشی برای او مناسب است، به شرطی که خیلی سخت نباشد و این فرصت را برای او فراهم کند که به من بلیط بفروشد. به عبارت دیگر، ما یک هدف مشترک با او داریم. در GOST 34.003-90، این اصطلاح برای تعیین آن استفاده می شود هدف از فعالیت... هر گاه تماشاگر دیگری با بلیط در دست از پنجره دور شود و تئاتر کمی ثروتمندتر شود، این هدف از فعالیت محقق می شود.

توابع سیستم خودکار

چندین هدف از فعالیت می تواند وجود داشته باشد (و، به عنوان یک قاعده، وجود دارد). هر نتیجه ای که خارج از خود فعالیت مفید باشد را می توان هدف آن دانست. بنابراین، اگر صندوقدار نه تنها بلیت می فروشد، بلکه در پایان روز کاری، گزارش فروش را برای روسا تهیه می کند، تهیه گزارش روزانه را می توان یکی دیگر از اهداف فعالیت در نظر گرفت.

اگر یک کامپیوتر و یک چاپگر روی میز صندوقدار بگذاریم و رئیس صندوق دستوری صادر کند که بلیط ها و گزارش ها را در یک ویرایشگر متن تایپ کند و آنها را روی چاپگر چاپ کند، یک سیستم خودکار دریافت می کنیم. با توجه به ایده های مدرن، بسیار ابتدایی است، به طور رسمی تعریف gost را برآورده می کند. توجه داشته باشید که اهداف فعالیت در نتیجه اجرای سیستم خودکار تغییر نکرده است، تنها راه دستیابی به آنها تغییر کرده است. آنچه قبلاً "درست مثل آن" انجام می شد اکنون در چارچوب یک سیستم خودکار انجام می شود. مجموعه اقدامات یک سیستم خودکار با هدف دستیابی به یک هدف خاص، طبق GOST 34.003-90، نامیده می شود. عملکرد... توجه: هر چه در مورد آن فکر کنید، کارکنان بخشی از سیستم محسوب می شوند.

عملکرد یک سیستم خودکار یک مفهوم اساسی در GOST 34 است. یک سیستم خودکار، اول از همه، به عنوان مجموع عملکردهای آن و تنها پس از آن به عنوان یک دسته از "نرم افزار" و "سخت افزار" در نظر گرفته می شود. مهمتر از همه، آنچه که سیستم انجام می دهد، و از چه چیزی تشکیل شده است، ثانویه است.

موارد فوق می تواند خواننده را به این نتیجه برساند که یک و تنها یک عملکرد با هر هدف از فعالیت در یک سیستم خودکار مطابقت دارد. تصور چنین سیستمی آسان است، اما عمل متنوع تر است. از یک سو، فعالیت ها همیشه به طور کامل خودکار نیستند. حتی پس از معرفی یک سیستم خودکار، برخی از اهداف باید به صورت دستی محقق شوند. از سوی دیگر، از آنجایی که نتیجه مشابه در شرایط مختلفمی توان به روش های مختلف به دست آورد، چندین عملکرد را می توان به یک هدف از فعالیت در یک سیستم خودکار هدایت کرد، به عنوان مثال، فروش بلیط در گیشه و فروش بلیط در اینترنت. علاوه بر این، هر سیستم خودکار نیاز به تعمیر و نگهداری خاصی دارد، بنابراین لازم است مفهوم یک عملکرد کمکی معرفی شود. مثال معمولی- ایجاد پشتیبان گیریداده ها.

وظایف سیستم خودکار

در حالت کلی، هنگام انجام یک کارکرد، بخشی از کار توسط پرسنل انجام می شود و بخشی از کار توسط تجهیزات انجام می شود، مثلاً یک بلیط به طور خودکار چاپ می شود و توسط صندوقداران به صورت دستی برای خریدار صادر می شود. دنباله ای از اقدامات خودکار (sic) که منجر به نتیجه یک نوع معین می شود در GOST 34.003-90 نامیده می شود. وظیفه.

در اینجا تعریف مشکل کاملاً دقیق ذکر نشده است، اما در حال حاضر برای ما کافی است و این در نهایت برای کسی شرم آور نیست که استاندارد را به تنهایی بخواند. مهم این است که وظیفه به وضوح رسمی ترین بخش فعالیت خودکار باشد. می توان عملکردی را تصور کرد که به طور کامل به طور خودکار انجام می شود، برای مثال، عملکردی که در بالا ذکر شد پشتیبان گیری... در این حالت، عملکرد به یک وظیفه کاهش می یابد.

یک کار مشابه را می توان با انجام عملکردهای مختلف حل کرد. به عنوان مثال، اگر یک سیستم خودکار چندین عملکرد برای فروش بلیط داشته باشد، اجرای هر یک از آنها ممکن است در مقطعی نیاز به چاپ بلیط داشته باشد.

ترکیب سیستم خودکار

زیر سیستم ها

اگر سیستم خودکار به اندازه کافی پیچیده باشد، به تقسیم می شود زیر سیستم ها... یعنی چه، به اندازه کافی سخت، به اندازه کافی سخت برای گفتن. نظریه سیستم ها را توصیف می کند سطوح مختلفو معیارهای پیچیدگی در عمل، نیاز به جداسازی چندین زیرسیستم در یک سیستم خودکار اغلب به دلایل سازمانی و مالی ایجاد می شود، به عنوان مثال، زیرسیستم ها به صورت متوالی توسعه یافته و به بهره برداری می رسند.

اگرچه در GOST 34 واژه زیرسیستم بارها استفاده شده است، به نظر می رسد هیچ تعریف رسمی از این مفهوم وجود ندارد. تجربه حکم می کند که یک زیرسیستم بخشی از یک سیستم خودکار است، که همچنین با تعریف یک سیستم خودکار مطابقت دارد، به ویژه که دارای عملکردهای کامل است.

با بازگشت به مثال فروش بلیط، می توانیم تصمیم بگیریم که سیستم خودکار از دو زیر سیستم تشکیل شده است: یک زیر سیستم فروش بلیط و یک زیر سیستم برای تولید گزارش های روزانه. اجازه دهید فقط برای وضوح بیشتر توافق کنیم که صندوقدار بلیط ها را در یک ویرایشگر متنی تایپ می کند و در صفحات گسترده گزارش می دهد.

اجزاء

تخصیص اهداف فعالیت، عملکردهای یک سیستم خودکار و در صورت لزوم، زیرسیستم های آن تا حد زیادی ذهنی است و به دیدگاه موضوعی بستگی دارد که تصمیم به انجام این کار گرفته است. اگر نتیجه ای در زمینه حل مشکل مهم باشد، می توانیم آن را هدف در نظر بگیریم و در غیر این صورت از آن چشم پوشی کنیم. ما همچنین تا زمانی که تصمیمات ما با محتوای این مفهوم مغایرت نداشته باشد، سیستم خودکار را به زیرسیستم هایی تقسیم می کنیم که برای ما راحت باشد.

کامپوننت ها قسمت هایی هستند که ما در آن قرار داریم واقعیت عینیساخت یک سیستم خودکار سیستم از نظر فیزیکی از اجزای خود تشکیل شده است، بنابراین، تقسیم یک سیستم خودکار به اجزاء هدفمندترین است.

ما هر کامپوننت (اگر تجهیزات باشد) را خریداری، سوار و وصل می کنیم، (اگر برنامه ای باشد) نصب می کنیم و به طور جداگانه از سایر قطعات سرویس می دهیم. ما یک کامپیوتر خریدیم و روی میز گذاشتیم - این یک جزء است. ما یک ویرایشگر متن ویژه برای مجموعه ای از بلیط ها ایجاد کرده ایم - جزء دیگر. صفحات گسترده رایگان دانلود شده از اینترنت - دوباره یک جزء. و حتی خود صندوقدار نیز به نوعی جزء یک سیستم خودکار است.

ترکیب اجزای یک سیستم خودکار از نقطه نظر مستندسازی آن بسیار مهم است، زیرا مستندات فنی سیستم به عنوان یک سیستم و اجزاء به طور متفاوتی رفتار می شود. به طور کلی، باید توسعه یابد مردم مختلف، و با توجه به نوع قطعه بر اساس استانداردهای مختلفی طراحی شده است.

انواع وثیقه

یکی از دشوارترین مفاهیم برای یک کاربر تازه کار GOST 34 است نوع امنیت... این چه نوع امنیت است؟ آیا می توانید آن را ببینید یا لمس کنید؟ بفروشم یا بخرم؟

هر نوع پشتیبانی ترکیبی از اجزا یا راه حل های فنی با ماهیت خاص است. GOST 34 موارد زیادی را ذکر می کند انواع متفاوتما به طور مداوم هر یک از آنها را در اینجا شرح نمی دهیم، بلکه تنها قابل توجه ترین آنها را فهرست می کنیم:

• پشتیبانی اطلاعات - تمام داده ها و ابرداده هایی که سیستم با آنها کار می کند.
• نرم افزار - همه برنامه هایی که بخشی از سیستم هستند.
• پشتیبانی فنی - همه وسایل فنی(به عبارت دیگر تجهیزات، دستگاه ها) که بخشی از سیستم هستند.

یک بار دیگر تکرار می کنیم، اینها همه انواع وثیقه نیستند. ما حتی نمی توانیم با اطمینان بگوییم که آنها مهمترین هستند. به عنوان مثال، برای سیستم های کنترل خودکار فرآیندهای تکنولوژیکیپشتیبانی اندازه شناسی (APCS) از اهمیت بالایی برخوردار است. بسیاری از سیستم های خودکار نیاز به پشتیبانی پیچیده ریاضی و زبانی دارند. اما تصور یک سیستم خودکار که به طور کامل فاقد یکی از سه نوع پشتیبانی ذکر شده در بالا باشد (تمرین: آن را امتحان کنید) دشوار است.

GOST 34.601-90 فناوری اطلاعات. مجموعه ای از استانداردها برای سیستم های خودکار. سیستم های خودکار مراحل خلقت.

گ و اس و د آ ر س ت و ای ن ن ی س ت ان د ی ر ت س و ی ز آ س ر

تاریخ معرفی
از 1992/01/01

این استاندارد برای سیستم های خودکار (AS) مورد استفاده در انواع متفاوتفعالیت ها (تحقیق، طراحی، مدیریت و غیره)، از جمله ترکیبات آنها، ایجاد شده در سازمان ها، انجمن ها و شرکت ها (از این پس - سازمان ها).

استاندارد مراحل و مراحل ایجاد یک بلندگو را تعیین می کند. پیوست 1 حاوی محتوای کار در هر مرحله است.

1. مقررات عمومی

1.1. فرآیند ایجاد AU مجموعه ای از زمان بندی شده، به هم پیوسته، متحد در مراحل و مراحل کار است که اجرای آن برای ایجاد یک AU که الزامات مشخص شده را برآورده می کند، لازم و کافی است.

1.2. مراحل و مراحل ایجاد یک AU به عنوان بخشی از فرآیند ایجاد به دلایل برنامه ریزی منطقی و سازماندهی کار متمایز می شود و با یک نتیجه مشخص به پایان می رسد.

1.3. کار بر روی توسعه AU با توجه به مراحل و مراحل مورد استفاده برای ایجاد AU انجام می شود.

1.4. ترکیب و قوانین انجام کار در مراحل و مراحل تعیین شده توسط این استاندارد در اسناد مربوطه سازمان های درگیر در ایجاد انواع خاصی از نیروگاه های هسته ای تعیین می شود.

فهرست سازمان های دخیل در ایجاد AU در پیوست 2 آورده شده است.

2. مراحل و مراحل ایجاد AU

2.1. مراحل و مراحل ایجاد AU در حالت کلی در جدول نشان داده شده است.

	مراحل کار
1. تشکیل الزامات برای AU	1.1. بازرسی از تاسیسات و توجیه ضرورت ایجاد نیروگاه هسته ای. 1.2. شکل گیری الزامات کاربر برای بلندگو. 1.3. ثبت گزارش در مورد کار انجام شده و یک برنامه برای توسعه AU (تاکتیکی شرایط مرجع)
2. توسعه مفهوم AU.	2.1. مطالعه شی. 2.2. انجام کارهای تحقیقاتی لازم. 2.3. توسعه گزینه هایی برای مفهوم بلندگو که نیازهای کاربر را برآورده می کند. 2.4. ثبت گزارش از کار انجام شده.
3. شرایط مرجع.	توسعه و تصویب مشخصات فنی برای ایجاد AU.
4. طراحی اولیه.	4.1. توسعه راه حل های طراحی اولیه برای سیستم و قطعات آن. 4.2. توسعه مستندات برای AU و قطعات آن.
5. پروژه فنی.	5.1. توسعه راه حل های طراحی برای سیستم و قطعات آن. 5.2. توسعه مستندات برای AU و قطعات آن. 5.3. توسعه و اجرای مستندات برای عرضه محصولات برای تکمیل AU و (یا) الزامات فنی(مشخصات فنی) برای توسعه آنها. 5.4. توسعه تکالیف طراحی در قسمت های مجاور پروژه شی اتوماسیون.
6. اسناد کاری.	6.1. توسعه اسناد کاری برای سیستم و قطعات آن. 6.2. توسعه یا انطباق برنامه ها.
7. راه اندازی.	7.1. آماده سازی شی اتوماسیون برای راه اندازی NPP. 7.2. آموزش کارکنان. 7.3. مجموعه کامل AU با محصولات عرضه شده (نرم افزار و سخت افزار، مجتمع های نرم افزاری و سخت افزاری، محصولات اطلاعاتی). 7.4. کار ساخت و نصب. 7.5. راه اندازی کارهای. 7.6. آزمایشات اولیه 7.7. عملیات آزمایشی 7.8. آزمون های پذیرش
8. همراهی AU	8.1. انجام کار مطابق با تعهدات گارانتی. 8.2. خدمات پس از گارانتی.

2.2. مراحل مراحل انجام شده توسط سازمان های شرکت کننده در کار ایجاد AU در قراردادها و شرایط مرجع بر اساس این استاندارد تنظیم شده است.

مجاز است مرحله "طراحی پیش نویس" و مراحل جداگانه کار را در کلیه مراحل حذف و مراحل "طراحی فنی" و "مستندات کاری" را در یک مرحله "پروژه طراحی فنی" ترکیب کند. بسته به مشخصات سیستم های هسته ای در حال ایجاد و شرایط ایجاد آنها، انجام مراحل تکی کار قبل از اتمام مراحل قبلی، به موازات زمان اجرای مراحل کار، گنجاندن مراحل جدید کار مجاز است. .

ضمیمه 1
(مرجع)

1. در مرحله 1.1. «بازرسی از تأسیسات و توجیه لزوم ایجاد در نیروگاه هسته‌ای» در حالت کلی انجام می‌شود:

• الف) جمع آوری داده ها در مورد هدف اتوماسیون و فعالیت های انجام شده؛
• ب) ارزیابی کیفیت عملکرد تأسیسات و فعالیت های انجام شده، شناسایی مشکلاتی که حل آنها از طریق اتوماسیون امکان پذیر است.
• ج) ارزیابی (فنی و اقتصادی، اجتماعی و غیره) از امکان سنجی ایجاد AU.

2. در مرحله 1.2. "تشکیل الزامات کاربر برای AU" انجام می شود:

• الف) تهیه داده های اولیه برای تشکیل الزامات AS (ویژگی های شی اتوماسیون، شرح الزامات سیستم، محدود کردن هزینه های مجاز برای توسعه، راه اندازی و بهره برداری، اثر مورد انتظار از سیستم، شرایط ایجاد و عملکرد سیستم)؛
• ب) فرمول بندی و اجرای الزامات کاربر برای AU.

3. در مرحله 1.3. "تنظیم گزارش کار انجام شده و برنامه توسعه یک AU (تکلیف فنی و فنی)" گزارشی از کارهای انجام شده در این مرحله تهیه می کند و یک برنامه کاربردی برای توسعه یک AU (تاکتیکی و فنی) تهیه می کند. تکلیف فنی) یا سند دیگری که آن را با محتوای مشابه جایگزین می کند.

4. در مراحل 2.1. "مطالعه شی" و 2.2. "انجام کار تحقیقاتی"، سازمان توسعه دهنده مطالعه دقیقی از شی اتوماسیون و کار تحقیقاتی لازم (R&D) مربوط به یافتن راه ها و ارزیابی امکان اجرای الزامات کاربر، تهیه و تایید گزارش های تحقیق و توسعه انجام می دهد.

5. در مرحله 2.3. "توسعه گزینه هایی برای مفهوم AU و انتخاب نسخه ای از مفهوم AU که نیازهای کاربر را برآورده می کند" در حالت کلی، گزینه های جایگزین برای مفهوم AU ایجاد شده و برنامه هایی برای اجرای آنها ایجاد کنید. ارزیابی منابع لازم برای اجرا و نگهداری آنها؛ ارزیابی مزایا و معایب هر گزینه؛ تعیین روش برای ارزیابی کیفیت و شرایط پذیرش سیستم؛ ارزیابی اثرات دریافتی از سیستم

6. در مرحله 2.4. «تنظیم گزارش کار انجام شده» گزارشی حاوی شرح کار انجام شده در مرحله توصیف و توجیه نسخه پیشنهادی مفهوم سیستم تهیه و تنظیم می کند.

7. در مرحله 3.1. «تدوین و تصویب شرایط مرجع برای ایجاد نیروگاه هسته‌ای» توسعه، اجرا، موافقت و تصویب شرایط مرجع برای نیروگاه هسته‌ای و در صورت لزوم مشخصات فنی بخشی از نیروگاه هسته‌ای را انجام می‌دهد. نیروگاه هسته ای.

8. در مرحله 4.1. "توسعه راه حل های اولیه طراحی برای سیستم و قطعات آن" تعریف می کند: وظایف AU; عملکردهای زیرسیستم ها، اهداف و اثرات آنها؛ ترکیب مجموعه وظایف و وظایف فردی؛ مفهوم پایگاه اطلاعاتی، ساختار بزرگ آن؛ توابع سیستم مدیریت پایگاه داده؛ ترکیب سیستم محاسباتی؛ توابع و پارامترهای نرم افزار اصلی

9. در مرحله 5.1. "توسعه راه حل های طراحی برای سیستم و قطعات آن" ارائه راه حل های کلی برای سیستم و قطعات آن، ساختار عملکردی و الگوریتمی سیستم، برای عملکرد پرسنل و ساختار سازمانی، در مورد ساختار ابزار فنی، در مورد الگوریتم های حل مسائل و زبان های کاربردی، در مورد سازماندهی و نگهداری پایگاه اطلاعاتی، سیستم طبقه بندی و کدگذاری اطلاعات، بر روی نرم افزار.

10. در مراحل 4.2. و 5.2. "توسعه اسناد و مدارک برای NPP و قطعات آن" توسعه، اجرا، هماهنگی و تایید اسناد را به میزان لازم برای توصیف مجموعه کامل راه حل های طراحی اتخاذ شده و کافی برای کار بیشتر در مورد ایجاد NPP انجام می دهد. انواع اسناد - طبق GOST 34.201-89.

11. در مرحله 5.3. "توسعه و اجرای اسناد برای تامین محصولات برای تکمیل نیروگاه های هسته ای و (یا) الزامات فنی (مشخصات فنی) برای توسعه آنها" انجام: تهیه و اجرای اسناد برای تامین محصولات برای تکمیل نیروگاه های هسته ای. تعیین الزامات فنی و تهیه مشخصات فنی برای توسعه محصولاتی که به تولید انبوه نمی رسند.

12. در مرحله 5.4 "توسعه تکالیف طراحی در بخش های مجاور پروژه شی اتوماسیون" توسعه، ثبت، هماهنگی و تایید تکالیف طراحی را در بخش های مجاور پروژه شی اتوماسیون برای ساخت و ساز، برق، بهداشتی انجام دهید. و دیگر کار مقدماتیمرتبط با ایجاد AU.

13. در مرحله 6.1 "توسعه اسناد کاری برای سیستم و قطعات آن"، مستندات کاری تهیه می شود که حاوی تمام اطلاعات لازم و کافی برای اطمینان از عملکرد کار در راه اندازی NPP و بهره برداری آن و همچنین برای حفظ سطح ویژگی های عملیاتی (کیفیت) سیستم مطابق با تصمیمات طراحی اتخاذ شده، طراحی، هماهنگی و تایید آن. انواع اسناد مطابق با GOST 34.201-89.

14. در مرحله 6.2 "توسعه یا انطباق برنامه ها"، برنامه ها و نرم افزارهای سیستم توسعه می یابند، انتخاب، انطباق و (یا) اتصال نرم افزار خریداری شده، توسعه اسناد نرم افزار مطابق با GOST 19.101.

15. در مرحله 7.1 "آماده سازی شی اتوماسیون برای راه اندازی NPP" کار بر روی آماده سازی سازمانی شی اتوماسیون برای راه اندازی NPP انجام می شود، از جمله:

• اجرای راه حل های طراحی برای ساختار سازمانی کارخانه؛
• ارائه زیرمجموعه های موضوع مدیریت با مواد آموزشی و روش شناختی؛
• معرفی طبقه بندی کننده های اطلاعات

16. در مرحله 7.2 "آموزش پرسنل"، پرسنل آموزش می بینند و توانایی آنها برای اطمینان از عملکرد NPP آزمایش می شود.

17. در مرحله 7.3 "تکمیل AU با محصولات عرضه شده (نرم افزار و سخت افزار، مجتمع های نرم افزاری و سخت افزاری، محصولات اطلاعاتی)" اطمینان از دریافت قطعات تولید دسته ای و واحد، مواد و محصولات نصبی، انجام شود. کنترل ورودیکیفیت آنها

18. در مرحله 7.4 "کار ساخت و ساز و نصب" انجام دهید:

• اجرای کارهای ساخت ساختمان های تخصصی (امکان) برای استقرار تجهیزات فنی و پرسنل NPP.
• ساخت کانال های کابلی؛
• اجرای کار نصب وسایل فنی و خطوط ارتباطی؛
• تست تجهیزات فنی نصب شده؛
• تحویل وسایل فنی برای راه اندازی.

19. در مرحله 7.5 "راه اندازی" انجام دهید:

• تنظیم مستقل سخت افزار و نرم افزار،
• بارگذاری اطلاعات در پایگاه داده و بررسی سیستم برای نگهداری آن؛
• تنظیم پیچیده همه وسایل سیستم

20. در مرحله 7.6 "انجام آزمایشات اولیه" انجام دهید:

• الف) تست های AU برای عملکرد و انطباق با شرایط مرجع مطابق با برنامه و روش آزمایش های اولیه؛
• ب) رفع نقص و اصلاحات در اسناد مربوط به NPP، از جمله اسناد عملیاتی مطابق با گزارش آزمایش.
• ج) ثبت گواهی پذیرش نیروگاه هسته ای برای بهره برداری آزمایشی.

21. در مرحله 7.7 "عملیات آزمایشی" انجام دهید:

• عملیات آزمایشی NPP؛
• تجزیه و تحلیل نتایج عملیات آزمایشی NPP؛
• تجدید نظر (در صورت لزوم) نرم افزار AC;
• تنظیم اضافی (در صورت لزوم) وسایل فنی نیروگاه هسته ای.
• ثبت گواهی پایان عملیات آزمایشی.

22. در مرحله 7.8 "آزمون های پذیرش" انجام دهید:

• الف) آزمایش های مربوط به انطباق با مشخصات فنی مطابق با برنامه و روش های آزمون های پذیرش؛
• ب) تجزیه و تحلیل نتایج آزمایش AU و رفع نواقص شناسایی شده در طول آزمایش.
• ج) ثبت قبولی نیروگاه هسته ای برای بهره برداری دائم.

23. در مرحله 8.1 "انجام کار مطابق با تعهدات گارانتی"، کار برای رفع نواقص شناسایی شده در طول عملیات NPP در طول تاسیس انجام می شود. دوره های گارانتی، تغییرات لازم را در اسناد AU ایجاد می کند.

24. در مرحله 8.2 "خدمات پس از گارانتی" کار در موارد زیر انجام می شود:

• الف) تجزیه و تحلیل عملکرد سیستم؛
• ب) شناسایی انحرافات مشخصات عملیاتی واقعی NPP از مقادیر طراحی.
• ج) تعیین دلایل این انحرافات.
• د) رفع نواقص شناسایی شده و اطمینان از ثبات ویژگی های عملیاتی NPP.
• ه) ایجاد تغییرات لازم در اسناد AU.

ضمیمه 2
(مرجع)

فهرست سازمان های شرکت کننده در کار ایجاد AU.

1. سازمان-مشتری (کاربر) که اتحادیه اتحادیه برای آن ایجاد شده و تأمین مالی، پذیرش کار و عملیات اتحادیه اروپا و همچنین اجرا را فراهم می کند. کارهای فردیبرای ایجاد AU

2. سازمان توسعه دهنده که کار ایجاد AU را انجام می دهد، مجموعه ای از خدمات علمی و فنی را در مراحل و مراحل مختلف ایجاد به مشتری ارائه می دهد و همچنین ابزارهای نرم افزاری و سخت افزاری مختلف را برای اتحادیه AU توسعه و ارائه می کند. .

3. سازمان تامین کننده ای که به درخواست توسعه دهنده یا مشتری نرم افزار و سخت افزار را تولید و عرضه می کند.

4. سازمان-طراح عمومی شی اتوماسیون.

5. سازمان ها - طراحان بخش های مختلف پروژه شی اتوماسیون برای انجام کارهای ساختمانی، برقی، بهداشتی و سایر کارهای مقدماتی مربوط به ایجاد نیروگاه هسته ای.

6. سازمان برای ساخت و ساز، مونتاژ، راه اندازی و غیره.

یادداشت:

• الف) بسته به شرایط ایجاد یک AU، ترکیبات مختلفی از عملکردهای یک مشتری، یک توسعه دهنده، یک تامین کننده و سایر سازمان های دخیل در ایجاد یک AU امکان پذیر است.
• ب) مراحل و مراحل کار آنها در ایجاد AU بر اساس این استاندارد تعیین می شود.

GOST 24.104-85 سیستم های کنترل خودکار. الزامات عمومی (بخش 3 با GOST 34.603-92 جایگزین شده است) بخش 3 با GOST 34.603-92 جایگزین شده استبا فرمان کمیته دولتی استانداردهای اتحاد جماهیر شوروی در 20 دسامبر 1985 به شماره 4632، دوره معرفی ایجاد شد.

از 01.01 1987

این استاندارد برای سیستم های کنترل خودکار (ACS) در همه نوع (به جز سیستم های ملی) اعمال می شود و الزامات کلیبه طور کلی سیستم کنترل خودکار، عملکردهای سیستم کنترل خودکار، آمادگی پرسنل و انواع تعمیر و نگهداری سیستم کنترل خودکار، ایمنی و ارگونومی، انواع و روش انجام آزمایشات در طول راه اندازی کنترل خودکار سیستم، کامل بودن سیستم کنترل خودکار را تضمین می کند.

این استاندارد الزاماتی را برای ACS تعیین نمی کند که توسط ویژگی های اشیاء کنترل تعیین می شود. این الزامات در شرایط مرجع برای ایجاد یا توسعه هر ACS یا سایر اسناد نظارتی و فنی بخش مشتری ACS تنظیم شده است.

الزامات اضافی برای سیستم‌های کنترل خودکار برای فرآیندهای فن‌آوری، سیستم‌های کنترل خودکار برای شرکت‌ها، انجمن‌های صنعتی و علمی تولیدی، سیستم‌های کنترل خودکار صنعتی به ترتیب در ضمیمه‌های اجباری 1-3 ایجاد شده‌اند.

مرجع پیوست 4 برخی از اصطلاحات استفاده شده در استاندارد را توضیح می دهد.

1. الزامات برای ACS

1.1. الزامات برای ACS به عنوان یک کل

1.1.1. ACS از هر نوعی باید با الزامات این استاندارد، الزامات مشخصات فنی برای ایجاد یا توسعه آن (از این پس TOR برای ACS نامیده می شود) و همچنین الزامات اسناد نظارتی و فنی موجود در بخش مطابقت داشته باشد. مشتری ACS

1.1.2. راه اندازی ACS باید به نتایج مفید فنی، اقتصادی، اجتماعی یا موارد دیگر منجر شود، به عنوان مثال:

• کوچک کردن پرسنل مدیریت;
• بهبود کیفیت عملکرد شی کنترل؛
• بهبود کیفیت مدیریت و غیره

1.1.3. محتوای خاص مورد نیاز برای PP. 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 در مشخصات فنی برای ACS نصب شده است.

1.1.4. ACS باید از دستیابی به اهداف ایجاد (توسعه) خود که در مشخصات فنی برای ACS تعیین شده است اطمینان حاصل کند.

1.1.5. ACS باید از سازگاری بین قطعات خود و همچنین با سیستم های خودکار (AS) متصل به این ACS اطمینان حاصل کند.

در مواردی که یک ACS یا مجموعه ای از ACS (AC) بر اساس یک شبکه کامپیوتری ایجاد می شود، برای اطمینان از سازگاری بین عناصر چنین شبکه ای، سیستم های پروتکل های تعامل چند سطحی باید اعمال شود.

1.1.6. ACS به عنوان یک کل و همه انواع پشتیبانی آن باید با نوسازی، توسعه و ایجاد مطابق با الزامات مشخص شده در مشخصات فنی برای ACS سازگار شود.

1.1.7. قابلیت اطمینان ACS به عنوان یک کل و هر یک از عملکردهای خودکار آن باید برای دستیابی به اهداف تعیین شده عملکرد سیستم تحت شرایط استفاده معین کافی باشد.

1.1.8. سازگاری ACS باید برای دستیابی به اهداف تعیین شده عملکرد آن در محدوده معینی از تغییرات در شرایط استفاده کافی باشد.

1.1.9. ACS باید نظارت بر صحت اجرای عملکردهای خودکار و تشخیص را فراهم کند و مکان، نوع و علت نقض عملکرد صحیح ACS را مشخص کند.

1.1.10. در سیستم کنترل خودکار با کانال های اندازه گیری، باید بتوان مشخصات مترولوژیکی کانال های اندازه گیری را کنترل کرد.

1.1.11. ACS باید اقداماتی را برای محافظت در برابر اقدامات نادرست پرسنل که منجر به وضعیت اضطراری یک شی یا سیستم کنترل می شود، از تغییرات تصادفی و تخریب اطلاعات و برنامه ها و همچنین در برابر تداخل غیرمجاز فراهم کند.

1.1.12. هر گونه اطلاعاتی که وارد ACS می شود یک بار با کمک یک کانال ورودی وارد سیستم می شود، در صورتی که این امر منجر به عدم تحقق الزامات تعیین شده در مشخصات فنی برای ACS (از نظر قابلیت اطمینان، قابلیت اطمینان و غیره) نشود. .

1.1.13. اطلاعات خروجی از محتوای معنایی یکسان باید بدون توجه به تعداد مخاطبان، یک بار در ACS تولید شود.

1.1.14. اطلاعات موجود در پایگاه داده های ACS باید مطابق با دفعات استفاده از آن هنگام انجام عملکردهای سیستم به روز شود.

1.1.15. ACS باید از نشت اطلاعات محافظت شود، در صورتی که در مشخصات فنی ACS قید شده باشد.

1.1.16. نام ACS باید شامل نام نوع ACS و شیء کنترل باشد.

مثلا:

• سیستم کنترل فرآیند خودکار برای گرم کردن فلز در یک کوره پیوسته.
• سیستم کنترل خودکار سازمانی و فناوری برای فروشگاه شماره 5;
• سیستم کنترل خودکار کارخانه "داس و چکش".

1.2. الزامات برای توابع ACS

1.2.1. ACS در حجم های مورد نیازباید به طور خودکار انجام شود:

• جمع آوری، پردازش و تجزیه و تحلیل اطلاعات (سیگنال ها، پیام ها، اسناد و غیره) در مورد وضعیت شی کنترل؛
• توسعه اقدامات کنترلی (برنامه ها، طرح ها و غیره)؛
• انتقال اقدامات کنترلی (سیگنال ها، دستورالعمل ها، اسناد) برای اجرا و کنترل آن؛
• اجرا و کنترل اجرای اقدامات کنترلی؛
• تبادل اطلاعات (اسناد، پیام ها و غیره) با سیستم های خودکار متصل به هم.

1.2.2. ترکیب عملکردهای خودکار (وظایف، مجموعه وظایف - که از این پس به عنوان توابع نامیده می شود) ACS باید توانایی کنترل شی مربوطه را مطابق با هر یک از اهداف تعیین شده در مشخصات فنی برای ACS فراهم کند.

1.2.3. ترکیب عملکردهای خودکار ACS و درجه اتوماسیون آنها باید از نظر فنی، اقتصادی و (یا) اجتماعی توجیه شود، با در نظر گرفتن نیاز به رهایی پرسنل از انجام اقدامات تکراری و ایجاد شرایط برای استفاده از توانایی های خلاقانه آنها در این فرآیند.

1.3. الزامات برای آموزش پرسنل ACS

1.3.1. صلاحیت پرسنل ACS باید عملکرد موثر سیستم را در تمام حالت های مشخص شده تضمین کند.

1.3.2. پرسنل ACS باید برای انجام وظایف خود مطابق با دستورالعمل های پشتیبانی سازمانی آماده باشند.

1.3.3. هر فردی که بخشی از پرسنل ACS است باید مدل های اطلاعاتی مناسب را اعمال کند و با وسایل فنی مورد استفاده خود و مستنداتی که ترتیب فعالیت های او را تعیین می کند کار کند.

1.4. الزامات پشتیبانی فنی ACS

1.4.1. مجموعه وسایل فنی ACS باید برای انجام تمام عملکردهای خودکار ACS کافی باشد.

1.4.2. مجموعه وسایل فنی ACS باید عمدتاً از وسایل فنی تولید سریال استفاده کند. در صورت لزوم، استفاده از وسایل فنی یک تولید مجاز است.

1.4.3. ACS تکراری و قطعات آن باید بر اساس ابزار فنی یکپارچه ساخته شوند.

1.4.4. ابزار فنی سیستم کنترل خودکار باید مطابق با الزامات مندرج در اسناد فنی، از جمله عملیاتی، برای آنها باشد و به گونه ای باشد که استفاده از آنها در حین عملکرد سیستم کنترل خودکار و انجام تعمیر و نگهداری راحت باشد.

1.4.5. قرار دادن وسایل فنی مورد استفاده توسط پرسنل سیستم کنترل خودکار هنگام انجام عملکردهای خودکار باید با الزامات ارگونومی مطابقت داشته باشد: برای تجهیزات تولید مطابق با GOST 12.049-80، برای ابزار ارائه اطلاعات بصری مطابق با GOST 21829-76. ، از جمله تخته های استفاده جمعی از نشانگرهای الکترولومینسنت سنتز علائم دیجیتال مطابق با GOST 21837-76.

1.4.6. ابزار فنی سیستم کنترل خودکار مورد استفاده در تعامل سیستم کنترل خودکار با سایر سیستم ها باید با وسایل فنی مربوطه این سیستم ها و سیستم های ارتباطی مورد استفاده سازگار باشد.

1.4.7. در ACS باید از وسایل فنی با طول عمر حداقل ده سال استفاده شود. استفاده از وسایل فنی با طول عمر کمتر تنها در موارد موجه و با توافق با مشتری سیستم کنترل خودکار مجاز است.

1.4.8. هر یک از ابزارهای فنی سیستم کنترل خودکار باید بدون هیچ گونه تغییر یا تنظیم ساختاری در سایر ابزارهای فنی سیستم کنترل خودکار (به استثنای مواردی که به طور خاص در اسناد فنی برای سیستم خودکار تصریح شده است) جایگزین آن با وسیله ای با اهداف عملکردی مشابه باشد. سیستم کنترل).

1.4.9. ابزار فنی سیستم کنترل خودکار فقط تحت شرایطی که در اسناد عملیاتی برای آنها مشخص شده است قابل استفاده است. در مواردی که لازم است از آنها در محیطی استفاده شود که پارامترهای آن از مقادیر مجاز تعیین شده برای این وسایل فنی فراتر رود، باید اقداماتی برای محافظت از وسایل فنی فردی ACS از تأثیر عوامل تأثیرگذار خارجی انجام شود.

1.4.10. در ACS باید از تجهیزات رایانه ای استفاده شود که الزامات فنی عمومی را مطابق با GOST 22552-84 برآورده می کند.

1.4.11. در ACS، باید از ابزارهای فنی استفاده شود که مطابق با:

• برای مقاومت در برابر عوامل تأثیرگذار خارجی - GOST 12997-76 برای دستگاه های صنعتی و تجهیزات اتوماسیون برای GSP، GOST 14254-80 برای پوسته های محصولات الکتریکی، GOST 17516-72 برای محصولات الکتریکی از نظر تأثیر عوامل مکانیکی محیط خارجی GOST 21552-84 برای فناوری رایانه؛
• از نظر منبع تغذیه - GOST 12997-76 برای دستگاه های صنعتی و تجهیزات اتوماسیون برای GSP، GOST 21552-84 برای تجهیزات کامپیوتری.
• بر اساس طبقه بندی اجرا - GOST 12997-76 برای دستگاه های صنعتی و تجهیزات اتوماسیون برای GSP، GOST 21552-84 برای تجهیزات کامپیوتری.

1.4.12. حفاظت از وسایل فنی سیستم کنترل خودکار در برابر اثرات میدان های الکتریکی و مغناطیسی خارجی و همچنین نویز در مدارهای منبع تغذیه باید کافی باشد تا وسایل فنی به طور مؤثر هدف خود را در طول عملکرد کنترل خودکار انجام دهند. سیستم.

1.4.13. در ACS، مطابق با الزامات ارائه شده توسط "استانداردهای اتحادیه مجاز تداخل صنعتی" 1-72 - 9-72 و GOST 23450-79، باید اقداماتی برای محافظت از محیط خارجی از تداخل رادیویی صنعتی ساطع شده انجام شود. توسط ابزار فنی ACS در حین کار و همچنین در لحظه روشن و خاموش شدن.

1.4.14. الزامات ارگونومی عمومی برای نمودارهای تقلید - مطابق با GOST 21480-76، برای محاسبه دستگاه های نشانگرهای بصری - مطابق با GOST 22902-78، برای تخته های استفاده جمعی در نشانگرهای الکترولومینسانس سنتز علائم دیجیتال - مطابق با GOST 21837-76، برای لوله های اشعه کاتدی برای نمایش اطلاعات بصری - طبق GOST 23144-78.

1.4.15. الزامات ارگونومی عمومی برای سوئیچ ها روی کنسول ها: چرخشی - مطابق با GOST 22613-77، صفحه کلید و دکمه های فشاری - مطابق با GOST 22614-77، نوع "Tumbler" - مطابق با GOST 22615-77.

1.4.16. الزامات ارگونومیک عمومی برای دستگاه های سیگنال دهی پیام های صوتی اولیه - مطابق با GOST 21786-76.

1.4.17. الزامات عمومی ارگونومیک حاکم بر سازمان محل کار، ترتیب متقابل وسایل نمایش اطلاعات، کنترل ها و امکانات ارتباطی در محل کار - مطابق با GOST 22269-76، از جمله کنسول ها - مطابق با GOST 23000-76.

1.4.18. الزامات عمومی ارگونومیک برای صندلی های اپراتور مطابق با GOST 21889-76.

1.4.19. الزامات عمومی ارگونومیک برای سالن، کابین اپراتور و ترتیب متقابل صندلی ها مطابق با GOST 21958-76 است.

1.5. الزامات نرم افزار ACS

1.5.1. نرم افزار ACS باید برای انجام تمام عملکردهای ACS اجرا شده با استفاده از فناوری رایانه کافی باشد، و همچنین دارای ابزاری برای سازماندهی کلیه فرآیندهای پردازش داده های مورد نیاز باشد که امکان اجرای به موقع همه عملکردهای خودکار را در همه حالت های تنظیم شده عملکرد ACS فراهم می کند.

1.5.2. نرم افزار ACS باید دارای ویژگی های زیر باشد:

• کفایت عملکردی (کامل)؛
• قابلیت اطمینان (از جمله قابلیت بازیابی، در دسترس بودن ابزارهای تشخیص خطا)؛
• تطبیق پذیری؛
• قابل تغییر؛
• مدولار بودن ساخت و ساز و
• راحتی در استفاده.

1.5.3. نرم‌افزار ACS باید عمدتاً بر اساس بسته‌های نرم‌افزاری موجود و سایر برنامه‌های قرض‌گرفته‌شده از دولت، صنعت و سایر بودجه‌های الگوریتم‌ها و برنامه‌ها ساخته شود، اجازه بارگذاری و تأیید در قطعات را بدهد و امکان جایگزینی برخی از برنامه‌ها را بدون اصلاح برخی دیگر فراهم کند.

1.5.4. در ACS، سیستم های مدیریت پایگاه داده (DBMS) که به روش مقرر ثبت شده اند، باید عمدتا استفاده شوند.

1.5.5. نرم افزار ACS باید به گونه ای طراحی شود که عدم وجود داده های جداگانه بر عملکرد عملکردهای ACS که در اجرای آنها از این داده ها استفاده نمی شود، تأثیری نداشته باشد.

1.5.6. نرم افزار ACS باید دارای ابزارهای تشخیصی برای سخت افزار ACS و کنترل صحت اطلاعات ورودی باشد.

1.5.7. نرم افزار ACS باید اقداماتی را برای محافظت در برابر خطاها در ورودی و پردازش اطلاعات اجرا کند و از کیفیت مشخص عملکرد عملکردهای ACS اطمینان حاصل کند.

1.5.8. نرم افزار عمومی ACS باید امکان تنظیم اجزای نرم افزار ویژه و توسعه بیشتر نرم افزار ACS را بدون وقفه در روند عملکرد آن فراهم کند. نرم افزاری که قبلاً تولید و بارگذاری شده است باید از تغییرات تصادفی محافظت شود.

1.5.9. تمام برنامه های نرم افزار ویژه یک ACS خاص باید هم با یکدیگر و هم با نرم افزار عمومی آن سازگار باشند.

1.5.10. مستندات نرم افزار عملیاتی برای سیستم کنترل خودکار باید مطابق با استانداردهای ESPD باشد و حاوی تمام اطلاعات لازم برای پرسنل سیستم کنترل خودکار برای استفاده از نرم افزار، برای بارگیری اولیه و (یا) تولید، دانلود اطلاعات از داخل نرم افزار باشد. پایگاه اطلاعات ماشین، برنامه های سیستم کنترل خودکار را راه اندازی کنید و عملکرد آنها را با استفاده از تست های مناسب بررسی کنید.

1.5.11. محصولات نرم افزاری جدید توسعه یافته برای ایجاد یک ACS خاص، که در نرم افزار آن گنجانده شده است، باید در دولت، صنعت یا سایر صندوق های الگوریتم ها و برنامه ها (در صورت لزوم) ثبت شوند.

1.6. الزامات پشتیبانی اطلاعاتی ACS

1.6.1. پشتیبانی اطلاعاتی ACS باید برای انجام تمام عملکردهای خودکار ACS کافی باشد.

1.6.2. برای رمزگذاری اطلاعاتی که فقط در این ACS استفاده می شود، باید از طبقه بندی کننده های پذیرفته شده توسط مشتری ACS استفاده شود.

1.6.3. برای کدگذاری در ACS اطلاعات خروجی مورد استفاده در سطح بالاتر، طبقه‌بندی‌کننده‌های سیستم‌های کنترل بالاتر باید اعمال شوند، به استثنای موارد خاص.

1.6.4. الزامات عمومی ارگونومیک برای کدگذاری اطلاعات - مطابق با GOST 21829-76.

1.6.5. در ACS، برای ارتباط بین دستگاه های مجموعه ای از وسایل فنی، باید از موارد زیر استفاده شود:

• سیگنال های ورودی و خروجی:
  • الکتریکی - جریان و ولتاژ مطابق با GOST 26.011-80، با تغییر گسسته پارامترها مطابق با GOST 26.013-81، کدگذاری شده مطابق با GOST 26.014-81،
  • هیدرولیک مطابق با GOST 26.012-80،
  • پنوماتیک مطابق با GOST 26.015-81؛
• مجموعه حروف عددی شخصیت مطابق با GOST 19767-74.
• کدهای 8 بیتی مطابق با GOST 19768-74.

1.6.6. پشتیبانی اطلاعاتی ACS باید از نظر محتوا، سیستم کدگذاری، روش‌های آدرس‌دهی، قالب‌های داده و شکل ارائه اطلاعات دریافتی و صادر شده توسط ACS با پشتیبانی اطلاعاتی سیستم‌های در حال تعامل با آن سازگار باشد.

1.6.7. فرم اسناد ایجاد شده توسط ACS باید با الزامات استانداردهای DCS یا اسناد نظارتی و فنی بخش مشتری ACS مطابقت داشته باشد.

1.6.8. فرم های اسناد و فریم های ویدئویی ورودی، خروجی یا تصحیح شده از طریق پایانه های سیستم کنترل خودکار باید با مربوطه توافق شود. مشخصات فنیپایانه ها

1.6.9. مجموعه آرایه های اطلاعاتی ACS باید در قالب پایگاه های داده در رسانه های کامپیوتری سازماندهی شود.

1.6.10. فرم ارائه اطلاعات خروجی ACS باید با مشتری (کاربر) سیستم به توافق برسد.

1.6.11. اصطلاحات و اختصارات استفاده شده در اسناد خروجی ACS باید به طور کلی در حوزه موضوعی مورد نظر پذیرفته شده و با مشتری سیستم موافقت شود.

1.6.12. ACS باید اقدامات لازم را برای کنترل و به روز رسانی داده ها در آرایه های اطلاعاتی ACS، بازیابی آرایه ها پس از خرابی هر وسیله فنی ACS و همچنین کنترل هویت اطلاعات به همین نام در پایگاه های داده

1.7. الزامات پشتیبانی سازمانی ACS

1.7.1. پشتیبانی سازمانی سیستم کنترل خودکار باید برای عملکرد مؤثر پرسنل سیستم کنترل خودکار مسئولیت های محول شده به آن در اجرای وظایف خودکار در اجرای عملکردهای خودکار و غیر خودکار سیستم کافی باشد.

1.7.2. ساختار سازمانی ACS باید امکان انجام تمام وظایف ACS را با در نظر گرفتن توزیع آنها بر اساس سطوح مدیریتی فراهم کند.

1.7.3. الزامات توزیع وظایف بین پرسنل شرکت کننده در عملیات سیستم کنترل خودکار در زمان واقعی با در نظر گرفتن الزامات بند 11 پیوست 1 اجباری تعیین می شود.

1.7.4. دستورالعمل های پشتیبانی سازمانی ACS باید اقدامات پرسنل ACS لازم برای انجام هر عملکرد خودکار را در تمام حالت های عملیاتی ACS با در نظر گرفتن الزامات مشخص شده برای دقت و سرعت اجرا توسط پرسنل ACS تعیین کند. مسئولیت های عملکردی، و همچنین حاوی دستورالعمل های خاص در مورد اقدامات در مواقع اضطراری یا نقض شرایط عادی عملکرد ACS است. الزامات محتوای دستورالعمل ها - مطابق با GOST 24.209-80.

1.7.5. برای هر عملکرد خودکاری که در تعامل این سیستم کنترل خودکار با سایر سیستم‌ها انجام می‌شود، دستورالعمل‌هایی به پرسنل سیستم کنترل خودکار و این سیستم‌ها باید برای همه حالت‌های انجام این عملکرد به هم متصل شده و حاوی دستورالعمل‌هایی در مورد اقدامات پرسنل در صورت وقوع باشد. خرابی ابزار فنی سیستم کنترل خودکار.

1.8. الزامات پشتیبانی زبانی ACS

1.8.1. پشتیبانی زبانی ACS باید برای ارتباط دسته های مختلف کاربران به شکلی مناسب برای آنها با اتوماسیون ACS و برای اجرای رویه های تبدیل و نمایش ماشینی اطلاعات پردازش شده در ACS کافی باشد.

1.8.2. پشتیبانی زبانی ACS باید شامل موارد زیر باشد:

• پیش بینی شده است زبان یعنیبرای توصیف هر گونه اطلاعات استفاده شده در ACS؛
• ابزارهای زبان مورد استفاده یکپارچه هستند.
• توصیفات مربوط به همان نوع عناصر اطلاعاتی و ضبط ساختارهای نحوی استاندارد شده است.
• راحتی، منحصر به فرد بودن و ثبات ارتباط بین کاربران و وسایل اتوماسیون ACS فراهم شده است.
• وسایل تصحیح خطاهایی که هنگام ارتباط کاربران با وسایل فنی ACS بوجود می آیند ارائه شده است.

1.8.3. پشتیبانی زبانی ACS باید در اسناد (دستورالعمل ها، توضیحات) پشتیبانی سازمانی ACS در قالب قوانینی برای برقراری ارتباط با کاربران با وسایل فنی ACS در تمام حالت های عملکرد سیستم منعکس شود.

1.9. الزامات پشتیبانی قانونی ACS

پشتیبانی قانونی ACS باید شامل مجموعه ای از مقررات قانونی:

• تعیین نیروی قانونی اطلاعات مربوط به حامل های داده و اسناد مورد استفاده در عملیات ACS و ایجاد شده توسط سیستم؛
• تنظیم روابط حقوقی بین افرادی که بخشی از پرسنل ACS هستند (حقوق، وظایف و مسئولیت‌ها)، و همچنین بین پرسنل ACS و پرسنل سیستم‌هایی که با ACS در تعامل هستند.

توجه داشته باشید.قوانین و مقررات ناشی از نیروی قانونی اطلاعات مربوط به حامل های داده و هنجارهای قانونی باید در دستورالعمل های پشتیبانی سازمانی و مقررات مربوط به خدمات ACS درج شود.

1.10. الزامات اسناد عملیاتی برای ACS

1.10.1. اسناد عملیاتی برای سیستم کنترل خودکار باید برای راه اندازی سیستم کنترل خودکار و عملکرد مؤثر آن کافی باشد.

1.10.2. اسناد عملیاتی برای ACS باید:

• حاوی اطلاعات لازم برای توسعه سریع و با کیفیت بالا و عملکرد صحیح سیستم های کنترل خودکار.
• حاوی دستورالعمل های مربوط به فعالیت های پرسنل ACS در موقعیت های اضطرارییا در صورت نقض شرایط عملیات عادی ACS؛
• حاوی مقررات مبهم نباشد.

2. الزامات ایمنی

2.1. اقدامات نادرست پرسنل ACS نباید منجر به اورژانس شود.

2.2. الزامات ایمنی برای محصولات الکتریکی مورد استفاده در سیستم های کنترل خودکار مطابق با GOST 12.2.007.0-75 است.

2.3. الزامات ایمنی برای تجهیزات کامپیوتری مورد استفاده در سیستم های کنترل خودکار مطابق با GOST 25861-83 است.

2.4. تمام عناصر خارجی ابزار فنی ACS که دارای انرژی هستند باید از تماس تصادفی محافظت شوند و خود وسایل فنی باید مطابق با GOST 12.1.030-81 و "قوانین تامین برق" دارای زمین یا زمین محافظ باشند.

2.5. ابزار فنی سیستم کنترل خودکار واقع در تاسیسات انفجاری و خطرناک آتش باید الزامات "قوانین تنظیم منبع تغذیه" را برآورده کند.

2.6. وسایل فنی ACS باید طوری نصب شوند که از عملکرد و نگهداری ایمن آنها اطمینان حاصل شود.

2.7. الزامات ایمنی باید توسط بخش خاصی تعیین شود شرح شغلو (یا) دستورالعمل های مربوط به عملکرد ACS و دارای پیوندهایی به دستورالعمل های عملکرد وسایل فنی است.

2.8. الزامات عمومی ارگونومیک برای محل کار پرسنل سیستم کنترل خودکار - مطابق با GOST 22269-76.

2.9. شرایط زندگی راحت برای پرسنل سیستم کنترل خودکار باید مطابق با استانداردهای بهداشتی فعلی باشد، حداکثر شرایط زندگی مجاز مطابق با GOST 12.1.005-76، سطوح مجاز تأثیر عوامل تولید خطرناک و مضر - مطابق با با GOST 12.0.003-74.

2.10. الزامات ارگونومیک عمومی برای میکروکلیمای اتاق های کار پرسنل ACS مطابق با GOST 12.1.005-76 است.

2.11. سطح نویز و قدرت صدا در مکان های پرسنل ACS نباید از مقادیر تعیین شده توسط GOST 12.1.003-83 و استانداردهای بهداشتی تجاوز کند، در حالی که سطوح نویز و توان صوتی تولید شده توسط همه منابع، از جمله دستگاه های انتقال داده های صوتی، باید در نظر گرفته شود.

2.12. سطوح روشنایی محل کار پرسنل ACS باید با ماهیت و شرایط کاری مطابقت داشته باشد. محافظت در برابر تابش خیره کننده و خیره کننده باید ارائه شود.

2.13. الزامات ارگونومیک عمومی برای لرزش تجهیزات در محل کار پرسنل ACS مطابق با GOST 12.1.012-78 است.

2.14. رنگ های سیگنال و علائم ایمنی مطابق با GOST 12.4.026-76.

3. انواع و مراحل آزمایش در هنگام شروع به کار ACS

این بخش برای تمام سیستم های کنترل خودکار اعمال می شود، به جز سیستم هایی که به دستور وزارت دفاع ایجاد شده اند.

3.1. ACS یا عملکرد جداگانه تحویل داده شده ACS (از این پس - ACS)، هنگام بهره برداری، باید تحت آزمایش های اولیه و پذیرش و همچنین آزمایش های ارائه شده توسط اسناد نظارتی و فنی در حال اجرا در بخش مشتری ACS قرار گیرد.

3.2. آزمایشات پذیرش ACS باید با عملیات آزمایشی آن در مرکز کنترل انجام شود.

3.3. تست های ACS مطابق با سند "برنامه آزمایشی" که توسط توسعه دهنده ACS تهیه شده است انجام می شود. الزامات محتوای برنامه آزمایشی - مطابق با GOST 24.208-80.

3.4. تست های ACS مجاز هستند در یک یا چند مرحله انجام شوند.

بر اساس نتایج آزمون ACS، یک "گزارش تست" تهیه می شود. الزامات محتوای گزارش آزمایش - مطابق با GOST 24.208-80.

در طی تست گام به گام ACS در "گزارش تست"، بر اساس نتایج مرحله قبل، باید در مورد امکان ارائه ACS برای مرحله بعدی آزمایش نتیجه گیری شود.

3.5. آزمایشات اولیه ACS

3.5.1. آزمایشات اولیه ACS برای تعیین عملکرد آن و حل مسئله امکان پذیرش ACS برای عملیات آزمایشی انجام می شود.

3.5.2. "برنامه تست" برای تست های اولیه ACS توسط مشتری ACS تایید شده است.

3.5.3. تست های اولیه ACS توسط مشتری سازماندهی شده و توسط توسعه دهنده ACS و مشتری با هم انجام می شود.

3.5.4. کمیسیون تست های اولیه ACS به سفارش مشتری تشکیل می شود. نماینده ای از مشتری ACS به عنوان رئیس کمیسیون منصوب می شود.

3.5.6. "گزارش آزمایش" که بر اساس نتایج آزمایش های اولیه ACS تهیه شده است، نتیجه گیری در مورد امکان پذیرش ACS برای عملیات آزمایشی و همچنین لیستی از پیشرفت های لازم و شرایط توصیه شده برای اجرای آنها ارائه می دهد.

3.6. عملیات آزمایشی ACS

3.6.1. نتایج پذیرش ACS در عملیات آزمایشی توسط "گواهی پذیرش عملیات آزمایشی" تهیه می شود که بر اساس "پروتکل تست" توسط کمیسیونی که آزمایش های اولیه ACS را انجام داده است تهیه می شود. الزامات محتوای قانون - مطابق با GOST 24.208-80.

3.6.2. مدت زمان عملیات آزمایشی ACS بر اساس زمان مورد نیاز برای بررسی عملکرد صحیح ACS در هنگام انجام هر عملکرد خودکار و آمادگی پرسنل ACS برای مشارکت در انجام کلیه عملکردهای خودکار ACS تعیین می شود.

3.6.3. حداقل مدت زمان عملیات آزمایشی ACS (به استثنای ACS) قبل از تعیین تست های پذیرش برای هر عملکرد خودکار ACS که تحویل داده می شود، باید با مقادیر نشان داده شده در جدول مطابقت داشته باشد. اگر مدت زمان کل اختلالات در تداوم عملکرد خودکار از مقدار مشخص شده در جدول بیشتر شود، عملیات آزمایشی باید تا حصول نتایج مربوط به جدول ادامه یابد یا تا زمانی که تصمیمی برای خاتمه آن گرفته شود.

پس از توافق با مشتری، مجاز است ACS را برای آزمایش های پذیرش بدون عملیات آزمایشی آن توابع خودکار ارسال کند، تعداد دفعات آن کمتر از یک بار در ماه است، مشروط بر اینکه نه تنها چنین عملکردهایی در ACS خودکار باشند.

فرکانس اجرای یک عملکرد خودکار	حداقل مدت عملیات آزمایشی ACS قبل از آزمون های پذیرش	مدت زمان کل مجاز اختلالات در تداوم عملکرد خودکار ACS
به طور مداوم	1 ماه	3 روز بیشتر نیست
یک بار در روز یا بیشتر	همچنین	بیش از 10٪ از تعداد راه حل های برنامه ریزی شده نیست
کمتر از یک بار در روز تا یک بار در ماه	3 ماه	همچنین
کمتر از یک بار در ماه تا هر شش ماه یک بار	فاصله بین دو تصمیم متوالی	نقض تداوم عملکرد مجاز نیست
یک بار در سال یا کمتر	مدت زمان مورد نیاز برای بررسی فناوری اتخاذ شده برای جمع آوری و پردازش اطلاعات در فرآیند اجرای یکبار عملکرد ACS	همچنین

یادداشت:

1. نقض تداوم عملکرد خودکار سیستم کنترل خودکار عدم انجام آن در زمان مقرر در اسناد فنی برای سیستم کنترل خودکار تلقی می شود، در صورتی که این امر ناشی از نقض شرایط برای سیستم کنترل خودکار نباشد. عملکرد سیستم کنترل خودکار یا شیء کنترلی.

2. اگر مدت زمان واقعی عملیات آزمایشی ACS بیشتر از زمان مشخص شده در ستون دوم جدول بود، کل مدت زمان ناپیوستگی اجرا برای هر عملکرد خودکار برای دوره زمانی مشخص شده در جدول و بلافاصله تعیین می شود. قبل از آزمون های قبولی

3.6.4. در طول عملیات آزمایشی ACS، یک گزارش کاری نگهداری می شود که در آن اطلاعات وارد می شود: در مورد مدت زمان عملیات ACS، در مورد نتایج نظارت بر عملکرد صحیح ACS، در مورد خرابی ها، خرابی ها، موارد اضطراری، در مورد تغییرات در پارامترهای شیء کنترلی و تنظیمات مربوط به اسناد فنی.

3.6.5. بر اساس نتایج عملیات آزمایشی، یک عمل تکمیل کار در مورد بررسی ACS در حالت عملیات آزمایشی ترسیم می شود. الزامات محتوای قانون - مطابق با GOST 24.208-80.

3.7. آزمون های پذیرش ACS

3.7.1. تست های پذیرش ACS برای تعیین انطباق آن با TOR برای ACS، الزامات این استاندارد و تعیین امکان راه اندازی ACS انجام می شود.

3.7.2. بسته به اهمیت شی کنترل و ACS، آزمون های پذیرش می توانند به صورت زیر باشند:

• دولت؛
• بین بخشی؛
• بخش

و باید توسط کمیته های پذیرش مربوطه انجام شود. کمیته پذیرش به دستور وزارت (بخش) مشتری ACS تشکیل می شود. سطح کمیته پذیرش باید در مشخصات فنی برای ACS تعیین شود.

3.7.3. نماینده ای از مشتری ACS به عنوان رئیس کمیته پذیرش منصوب می شود. کمیته پذیرش باید شامل نمایندگان توسعه دهنده ACS باشد.

3.7.4. کار کمیته پذیرش شامل پذیرش ساختمان ها، سازه ها و تجهیزات کمکی نمی شود که ایجاد آنها در ارتباط با ایجاد سیستم کنترل خودکار انجام شده است. کمیسیون فقط وجود اقداماتی را در مورد پذیرش آنها برای بهره برداری و برآورده شدن الزامات مندرج در تکالیف طراحی در بخش های مجاور پروژه تأسیسات صادر شده در هنگام طراحی سیستم کنترل خودکار بررسی می کند.

3.7.5. مشتری و توسعه دهنده اسناد زیر را به کمیته پذیرش ارائه می کنند:

• شرایط مرجع برای ایجاد یک سیستم کنترل خودکار؛
• پیش نویس برنامه آزمون پذیرش؛
• گزارش آزمایش اولیه ACS؛
• گواهی پذیرش ACS برای عملیات آزمایشی؛
• اقدام (ها) در مورد تکمیل کار برای بررسی ACS در حالت عملیات آزمایشی؛
• اسناد فنی برای ACS (با تصمیم کمیته پذیرش).

3.7.6. قبل از ارائه ACS با کانال های اندازه گیری برای آزمون های پذیرش، گواهی اندازه گیری آنها مطابق با استانداردهای قابل اجرا انجام می شود.

3.7.7. قبل از ارائه ACS برای آزمون های پذیرش، سیستم و مستندات فنی آن باید با توجه به تبصره های پروتکل آزمون اولیه و عمل به اتمام کار بررسی ACS در حالت عملیات آزمایشی نهایی شود.

با تصمیم کمیته پذیرش مجاز است اسناد فنی ACS را پس از بهره برداری مورد بازنگری قرار دهد. شرایط نهایی کردن مستندات فنی ACS در گزارش آزمون پذیرش سیستم ذکر شده است.

3.7.8. تست های پذیرش ACS باید در یک مرکز کنترل عملکردی انجام شود.

3.7.9. "برنامه آزمون" آزمون های قبولی ACS باید با تصمیمات کمیته پذیرش تایید شود. هماهنگی برنامه آزمون پذیرش با مشتری ACS الزامی است.

3.7.10. بر اساس نتایج آزمون های پذیرش، کمیسیون یک گزارش آزمایش و یک اقدام در مورد راه اندازی ACS (یا نتیجه گیری در مورد عدم پذیرش ACS با لیستی از بهبودهای لازم و مهلت های توصیه شده برای اجرای آنها) تهیه می کند. . الزامات محتوای پروتکل و مطابق با GOST 24.208-80 عمل کنید. الزامات محتوای نتیجه گیری در مورد عدم پذیرش ACS مشابه الزامات محتوای قانون راه اندازی ACS است.

3.7.11. در مورد آزمون پذیرش مرحله‌ای، بر اساس قوانین راه‌اندازی بخش‌های مجزای سیستم و (یا) "پروتکل‌های آزمایشی" تمام مراحل آزمایش‌های پذیرش ACS، قانون راه‌اندازی ACS تنظیم می‌شود.

3.7.12. تاریخ راه اندازی ACS، تاریخ امضای قانون راه اندازی توسط کمیسیون پذیرش در نظر گرفته می شود.

3.7.13. قانون راه اندازی ACS توسط وزارت (بخش) مشتری تایید می شود.

4. مجموعه کاملی از ACS متعهد به عملیات

4.1. ACS باید شامل موارد زیر باشد:

• سخت افزار ACS به شکل مجموعه ای از سخت افزار ACS که برای عملیات آماده شده است.
• محصولات و دستگاه‌های یدکی (قطعات یدکی)، دستگاه‌ها و دستگاه‌هایی برای آزمایش عملکرد، تنظیم ابزار فنی و نظارت بر ویژگی‌های اندازه‌شناسی کانال‌های اندازه‌گیری سیستم کنترل خودکار به میزان مقرر در سفارش مستندات پروژه، توافق با مشتری ACS و خدمات اندازه گیری کاربر از نظر تجهیزات تأیید؛
• اسناد عملیاتی مطابق با GOST 2.601-68 برای هر یک از محصولات موجود در CTS ACS.
• حداقل دو نسخه از برنامه های حامل های داده و اسناد عملیاتی برای آنها مطابق با GOST 19.101-77، با در نظر گرفتن محدودیت ها و اضافات مطابق با GOST 24.101-80 و GOST 24.207-80.
• فرمی برای نرم افزار ACS به طور کلی یا برای نرم افزار عملکرد ACS که به طور جداگانه به کار گرفته شده است و فرم هایی برای محصولات نرم افزاری (طبق GOST 19.004-80) هر کدام در یک نسخه. الزامات فرم - مطابق با GOST 19.501-78؛
• دو نسخه از اسناد عملیاتی برای ACS مطابق با GOST 24.101-80، از جمله اسناد لازم برای پشتیبانی اطلاعات ACS (فرم ACS در یک نسخه).

با توافق بین توسعه دهنده ACS و مشتری ACS، می توان کامل بودن ACS را افزایش داد.

4.2. کارکنان ACS باید دارای پرسنلی باشند که الزامات بند 1.3 را برآورده کنند.

4.3. برای تکمیل ACS ایجاد شده می توان از محصولات زیر که به عنوان تولید و هدف فنی عرضه می شود استفاده کرد:

• مجتمع (مجتمع) سخت افزار و نرم افزار با اسناد عملیاتی برای آنها مطابق با GOST 2.601-68.
• محصولات نرم افزاری با اسناد عملیاتی برای آنها مطابق با GOST 19.101-77؛
• وسایل فنی با اسناد عملیاتی برای آنها مطابق با GOST 2.601-68.

4.4. روش توسعه، راه اندازی به تولید و آزمایش اجزای عرضه شده مورد استفاده در سیستم کنترل خودکار باید با استانداردهای دولتی سیستم توسعه و راه اندازی محصولات مطابقت داشته باشد.

قبل از تولید، نمونه های اولیه قطعات تحت آزمایش های پذیرش (ایالتی، بین بخشی، دپارتمان) قرار می گیرند.

5. گارانتی

5.1. توسعه دهنده ACS مطابقت ACS با الزامات این استاندارد و مشخصات فنی ACS را به شرط رعایت شرایط و قوانین عملکرد توسط کاربر تضمین می کند.

5.2. انطباق سخت افزار، نرم افزار و تجهیزات اتوماسیون مورد استفاده در سیستم کنترل خودکار و عرضه شده به عنوان محصولات تولیدی و فنی با الزامات استانداردها و مشخصات فنی مربوط به آنها توسط سازندگان این نوع محصولات تضمین می شود، مشروط بر اینکه کاربر موارد لازم را رعایت کند. شرایط و قوانین عملیاتی

5.3. مدت گارانتی ACS از روزی که ACS راه اندازی می شود محاسبه می شود.

5.4. دوره گارانتی ACS باید در TK برای ACS تنظیم شود و نمی تواند کمتر از 18 ماه باشد.

ضمیمه 1
اجباری

الزامات اضافی برای سیستم های کنترل فرآیند خودکار (APCS)

1. APCS در صنعت و در حوزه غیر صنعتی باید هدف فناورانه را به عنوان یک کل کنترل کند و سیستم های متصل به آن را با اطلاعات فنی و فنی و اقتصادی قابل اعتماد در مورد عملکرد شی فناورانه کنترل (TOC) تامین کند.

2. APCS باید از نظر اهداف و معیارهای مدیریت اقدامات کنترلی بر روی TOU در زمان واقعی جریان فرآیند تکنولوژیکی در شیء کنترلی را توسعه و اجرا کند.

3. APCS باید کنترل، اطلاعات و عملکردهای کمکی را انجام دهد.

4. APCS باید با تمام سیستم‌های خودکار متصل (AS) مشخص شده در TK برای APCS، از جمله سیستم‌هایی که با این APCS در تولید خودکار انعطاف‌پذیر گنجانده شده‌اند، برای مثال، فناوری CAD، سیستم‌های انبار و حمل و نقل خودکار، AS برای آماده سازی تکنولوژیکی تولید

5. اقدامات کنترلی در APCS باید به طور خودکار ایجاد شود یا توسط پرسنل عملیاتی آن با استفاده از مجموعه ای از ابزارهای اتوماسیون موجود در سیستم تشکیل شود.

6. APCS باید از کنترل تاسیسات در شرایط عادی، گذرا و پیش اضطراری عملیات آن و همچنین حفاظت یا خاموش شدن تاسیسات در صورت تهدید حادثه اطمینان حاصل کند.

7. APCS باید عملکرد نظارت بر اجرای اقدامات کنترلی در TOU را انجام دهد و خروج دستگاه های اجرایی را به حداکثر موقعیت های مجاز سیگنال دهد.

8. هنگام اجرای عملکرد انحراف خودکار اضطراری تجهیزات در APCS باید به پرسنل عملیاتی به کمک نور هشدار داده شود و در صورت لزوم سیگنال های صوتیبا ثبت خودکار زمان خاموش شدن.

9. به عنوان ابزار فنی اصلی APCS، محصولات باید استفاده شود سیستم دولتیدستگاه‌های صنعتی و تجهیزات اتوماسیون (GSP)، سایر محصولاتی که الزامات استانداردهای ESSP را برآورده می‌کنند، و تجهیزات رایانه‌ای که با GOST 21552-84 مطابقت دارند.

10. وسایل فنی APCS که بر روی تجهیزات فناورانه قرار می گیرد باید با الزاماتی که شرایط عملیاتی بر آنها تحمیل شده است مطابقت داشته باشد.

11. مسئولیت ها بین اپراتورها باید با در نظر گرفتن موارد زیر تقسیم شود:

• مشارکت پرسنل در اجرای عملکردهای غیر خودکار سیستم و تعامل آن با سایر سیستم ها.
• سطح مجاز بار روانی فیزیولوژیکی و عاطفی اپراتورها که توسط اسناد هنجاری و فنی صنعت مرتبط با انجام وظایف محول شده به هر یک از آنها و مسئولیت وی در قبال نتایج نهایی و میانی کار و همچنین سطح مورد نیاز او تعیین شده است. فعالیت در فرآیند کار

12. هر فردی که جزء کارکنان است باید دارای:

• دانشی که حجم و عمق آن به او امکان می دهد اقدامات (تعاملات) موجود در عملکردهای غیر خودکار خودکار و به هم پیوسته مربوطه APCS را انجام دهد و همچنین در مواقع اضطراری یا در صورت سایر موارد نقض عادی تصمیمات صحیح اتخاذ کند. عمل؛
• مهارت های اثبات شده، اجازه می دهد تا تمام اقدامات و تعاملات را با دقت و سرعت مشخص انجام دهید.

13. نرم افزار ACS TP باید فراهم کند و پشتیبانی سازمانی منعکس کننده ابزار زبانی برای ارتباط پرسنل عملیاتی با CCS ACS TP است که برای افرادی که صلاحیت برنامه نویسی را ندارند راحت و قابل دسترسی است.

14. کدها و افسانهمورد استفاده در APCS باید به اصطلاحات و مفاهیم مورد استفاده توسط پرسنل فناوری شی کنترل نزدیک باشد و نباید در درک آنها مشکل ایجاد کند.

15. کانال های اندازه گیری APCS باید دارای ویژگی های اندازه شناسی باشد که عملکرد عملکرد اطلاعات آن را با شاخص های مشخص شده در مشخصات فنی برای APCS تضمین کند.

16. الزامات برای آزمایش ACS TP

16.1. آزمایشات اولیه APCS در TOU عامل انجام می شود.

16.2. آزمایش‌های اولیه عملکردهای APCS مورد نیاز برای راه‌اندازی و راه‌اندازی تجهیزات فرآیند ممکن است با استفاده از شبیه‌سازها در تأسیسات انجام شود.

16.3. تعیین مقادیر واقعی شاخص های بهره وری فنی و اقتصادی و قابلیت اطمینان APCS پس از راه اندازی آن انجام می شود. مدت زمان کارکرد APCS، لازم برای تعیین مقادیر واقعی شاخص های آن، بر اساس روش های مناسب، تایید شده به روش تعیین شده محاسبه می شود.

ضمیمه 2
اجباری

الزامات اضافی برای ACS برای شرکت ها، تولید و تحقیقات و انجمن های تولیدی

1. ACS باید کارایی تولید و فعالیت های اقتصادی بنگاه ها، تولید یا انجمن تحقیقات و تولید (از این پس - بنگاه ها) را افزایش دهد.

2. سیستم کنترل خودکار شرکت (AMCS) باید جمع‌آوری و پردازش خودکار اطلاعات را با استفاده گسترده از روش‌های بهینه‌سازی برای وظایف اصلی و زیرسیستم‌های کنترل در سطح کارخانه و کارگاه، از جمله، در صورت لزوم، به صورت واقعی فراهم کند. زمان در حالت پردازش از راه دور و گفتگو.

3. سیستم کنترل خودکار باید به عنوان مجموعه ای از زیرسیستم های با عملکرد مشترک پیاده سازی شود، که تعامل بین آنها باید از طریق یک پایگاه داده مشترک (تک یا توزیع شده) صورت گیرد.

4. پشتیبانی سازمانی از سیستم کنترل خودکار باید برای بهبود روش های مدیریت و ساختار سیستم مدیریت سازمانی در طول ایجاد و توسعه سیستم کنترل خودکار فراهم شود.

ضمیمه 3
اجباری

الزامات اضافی برای سیستم های کنترل خودکار صنعتی (AMS)

1. OASU باید ارائه دهد:

• بهبود ویژگی های هدف مدیریت (افزایش بهره وری نیروی کار در صنعت، بهبود کیفیت محصول، تحویل به موقع محصولات، کاهش هزینه محصولات).
• بهبود فرآیندهای پردازش اطلاعات (کاهش هزینه پردازش اطلاعات، افزایش قابلیت اطمینان اولیه، افزایش دقت و کارایی محاسبات).
• بهبود سازماندهی عملکرد توابع مدیریت (به ویژه توزیع منطقی کار بین بخش های دستگاه مدیریت، مراکز محاسباتی و سازمان ها و شرکت های تحقیقاتی).

2. OASU باید عملکردهای مدیریت صنعت خودکار داشته باشد، به عنوان مثال:

• پیش بینی و برنامه ریزی منابع تولید و صنعت.
• مدیریت توسعه علمی و فنی صنعت و آماده سازی فنی صنعت؛
• کنترل منابع کارصنعت؛
• کنترل منابع مادیصنعت؛
• مدیریت ساخت و ساز سرمایه در صنعت;
• کنترل منابع مالیصنعت؛
• مدیریت، از جمله عملیاتی، تولید اصلی در سطح صنعت و غیره.

3. OASU باید در قالب مجموعه ای از زیرسیستم های با عملکرد مشترک، که تعامل بین آنها باید از طریق پایگاه های داده مشترک صورت گیرد، پیاده سازی شود.

4. OASU باید شامل یک سیستم جمع آوری داده ها مبتنی بر مراکز محاسباتی OASU، سازمان ها و شرکت های صنعتی باشد که از توزیع منطقی اطلاعات در پایگاه های داده برای حل مشکلات متقابل و انتقال اطلاعات بین سیستم ها از طریق کانال های ارتباطی و رسانه های رایانه ای اطمینان حاصل کند. .

5. OASU باید یک حالت تعاملی کار با پایگاه های داده سیستم ارائه دهد.

6. ایجاد OASU باید به بهبود روش ها و ساختار مدیریت صنعت منجر شود.

7. مدت زمان عملیات آزمایشی قطعات OASU باید انجام یکباره کلیه محاسبات لازم برای انجام عملکردهای خودکار بخش معرفی شده OASU را تضمین کند و نباید از 3 ماه تجاوز کند.

مدت زمان مشخص عملیات آزمایشی OASU با توافق بین توسعه دهنده و مشتری تعیین می شود.

ضمیمه 4
ارجاع

توضیح برخی از اصطلاحات استفاده شده در این استاندارد

مجتمع اتوماسیون (KSA)- مجموعه عرضه شده از مجتمع های سخت افزاری و نرم افزاری (محصولات) مورد توافق طرفین که به عنوان محصولاتی برای اهداف صنعتی و فنی توسعه یافته و تولید می شوند. ترکیب KSA همچنین ممکن است شامل سایر محصولات و (یا) اسنادی باشد که بخشی از اطلاعات، سازمانی یا سایر انواع پشتیبانی برای سیستم های خودکار هستند.

ساختن ACS- مجموعه ای از اقدامات انجام شده در ACS هنگام گسترش شی کنترل آن بدون تغییر ترکیب عملکردهای ACS.

فریم ویدیو (در ACS)- یک تصویر روی صفحه یک لوله اشعه کاتدی از یک سند نقاشی یا متنی از یک پیام مورد استفاده در یک سیستم کنترل خودکار.

کانال اندازه گیری ACS- مجموعه ای ترکیبی از ابزارهای فنی و (در صورت لزوم) نرم افزاری که برای اجرای یک تابع اندازه گیری ساده ACS طراحی شده اند.

آزمایشات اولیه ACS- آزمایشات کنترلی انجام شده به منظور تعیین امکان پذیرش سیستم کنترل خودکار برای عملیات آزمایشی.

آزمون های پذیرش ACS- آزمایشات کنترلی سیستم کنترل خودکار، انجام شده برای تعیین انطباق آن با شرایط مرجع برای ایجاد یک سیستم کنترل خودکار، الزامات استانداردها و تعیین امکان راه اندازی سیستم کنترل خودکار.

آزمون های دولتی- آزمون های پذیرش ACS که توسط کمیسیون دولتی انجام شده است.

آزمون بین بخشی- آزمون های پذیرش ACS که توسط کمیسیونی از نمایندگان چندین وزارتخانه و (یا) بخش ذینفع انجام می شود.

تست دپارتمان- آزمون های پذیرش ACS که توسط کمیسیونی از نمایندگان وزارتخانه یا بخش ذینفع انجام می شود.

ویرایشگر A.I. لومینا
ویرایشگر فنی N.P. زامولودچیکووا
تصحیح کننده E.I. اوتیوا
اهدایی به مجموعه 16/01/86. امضا برای چاپ در 86.04.86. تبدیل چاپ ل 1.5. تبدیل cr.-Ott. 1.5 Uch.-ed. ل 1.5.
تیراژ 40000 قیمت 10 کوپک.
سفارش انتشارات استاندارد نشان افتخار، 123810، مسکو، GSP، Novopresnensky per.، 3
نوعی از. "چاپگر مسکو"، مسکو، لیالین در هر، 6. سفارش 1772

تاریخ معرفی 92/01/01

این استاندارد برای سیستم‌های خودکار (AS) که در فعالیت‌های مختلف (تحقیق، طراحی، مدیریت و غیره) استفاده می‌شوند، از جمله ترکیبات آنها، ایجاد شده در سازمان‌ها، انجمن‌ها و شرکت‌ها (از این پس سازمان‌ها نامیده می‌شوند) اعمال می‌شود.

استاندارد مراحل و مراحل ایجاد یک بلندگو را تعیین می کند. پیوست 1 حاوی محتوای کار در هر مرحله است.

1. مقررات عمومی

2. مراحل و مراحل ساخت اسپیکر

پیوست 1 (مرجع)

پیوست 2 (مرجع)

1. مقررات عمومی

1.1. مجموعه ای از زمان بندی شده، به هم پیوسته، متحد در مراحل و مراحل کار است که اجرای آن برای ایجاد یک AU که الزامات مشخص شده را برآورده می کند لازم و کافی است.

1.2. مراحل و مراحل ایجاد یک AU به عنوان بخشی از فرآیند ایجاد به دلایل برنامه ریزی منطقی و سازماندهی کار متمایز می شود و با یک نتیجه مشخص به پایان می رسد.

1.3. کار بر روی توسعه AU با توجه به مراحل و مراحل مورد استفاده برای ایجاد AU انجام می شود.

1.4. ترکیب و قوانین انجام کار در مراحل و مراحل تعیین شده توسط این استاندارد در اسناد مربوطه سازمان های درگیر در ایجاد انواع خاصی از نیروگاه های هسته ای تعیین می شود.

فهرست سازمان های دخیل در ایجاد AU در پیوست 2 آورده شده است.

2. مراحل و مراحل ایجاد AU

2.1. مراحل و مراحل ایجاد AU در حالت کلی در جدول نشان داده شده است.

مراحل	مراحل کار
1. تشکیل الزامات برای AU	1.1. بررسی محل و توجیه ضرورت ایجاد نیروگاه هسته ای
	1.2. شکل گیری الزامات کاربر برای بلندگو
	1.3. ثبت گزارش در مورد کار انجام شده و یک برنامه کاربردی برای توسعه AU (تکلیف تاکتیکی و فنی)
2. توسعه مفهوم AU	2.1. مطالعه شی
	2.2. انجام کارهای تحقیقاتی لازم
	2.3. توسعه انواع مفهوم بلندگو و انتخاب نسخه ای از مفهوم بلندگو که نیازهای کاربر را برآورده می کند.
	2.4. ثبت گزارش از کار انجام شده
3. شرایط مرجع	3.1. توسعه و تصویب مشخصات فنی برای ایجاد AU
4. پیش نویس پروژه	4.1. توسعه راه حل های طراحی اولیه برای سیستم و قطعات آن
	4.2. توسعه مستندات برای NPP و قطعات آن
5. طراحی فنی	5.1. توسعه راه حل های طراحی برای سیستم و قطعات آن
	5.2. توسعه مستندات برای NPP و قطعات آن
	5.3. تدوین و اجرای مستندات برای تامین محصولات تکمیل نیروگاه های هسته ای و (یا) الزامات فنی (مشخصات فنی) توسعه آنها.
	5.4. توسعه تکالیف طراحی در قسمت های مجاور پروژه شی اتوماسیون
6. اسناد کاری	6.1. توسعه اسناد کاری برای سیستم و قطعات آن
	6.2. توسعه یا انطباق برنامه ها
7. عملی کردن	7.1. آماده سازی شی اتوماسیون برای راه اندازی NPP
	7.2. آموزش کارکنان
	7.3. تکمیل سیستم بلندگو با محصولات ارائه شده (نرم افزار و سخت افزار، مجتمع های نرم افزاری و سخت افزاری، محصولات اطلاعاتی)
	7.4. کارهای ساختمانی و نصب
	7.5. راه اندازی کارهای
	7.6. آزمایشات اولیه
	7.7. عملیات آزمایشی
	7.8. آزمون های پذیرش
8. همراهی AU	8.1. انجام کار مطابق با تعهدات گارانتی
	8.2. خدمات پس از گارانتی

2.2. مراحل و مراحل انجام شده توسط سازمان ها - شرکت کنندگان در کار ایجاد AU، در قراردادها و شرایط مرجع بر اساس این استاندارد تعیین می شوند.

مجاز است مرحله "طراحی پیش نویس" و مراحل مجزای کار را در تمام مراحل حذف کند، مراحل "طراحی فنی" و "مستندات کاری" را در یک مرحله "طراحی فنی" ترکیب کند. بسته به مشخصات سیستم های هسته ای در حال ایجاد و شرایط ایجاد آنها، انجام مراحل تکی کار قبل از اتمام مراحل قبلی، به موازات زمان اجرای مراحل کار، گنجاندن مراحل جدید کار مجاز است. .

ضمیمه 1 مرجع

1. در مرحله 1.1 "بررسی تاسیسات و توجیه نیاز به ایجاد نیروگاه هسته ای"، در حالت کلی، انجام دهید:

• جمع آوری داده ها در مورد شی اتوماسیون و فعالیت های انجام شده؛
• ارزیابی کیفیت شی و فعالیت های انجام شده، شناسایی مشکلاتی که حل آنها با استفاده از اتوماسیون امکان پذیر است.
• ارزیابی (فنی، اقتصادی، اجتماعی و غیره) امکان سنجی ایجاد AU.

2. در مرحله 1.2 "تشکیل الزامات کاربر برای AU" انجام دهید:

• تهیه داده های اولیه برای تشکیل الزامات برای نیروگاه هسته ای (ویژگی های شی اتوماسیون، شرح الزامات سیستم، محدود کردن هزینه های مجاز برای توسعه، راه اندازی و بهره برداری، اثر مورد انتظار از سیستم، شرایط برای ایجاد و بهره برداری از سیستم)؛
• فرمول بندی و اجرای الزامات کاربر برای AU.

3. در مرحله 1.3 "اجرای گزارش در مورد کار انجام شده و برنامه ای برای توسعه یک AU (تکلیف تاکتیکی و فنی)"، گزارشی از کار انجام شده در این مرحله تهیه می شود و برنامه ای برای توسعه یک AU (تکلیف تاکتیکی و فنی) یا سند دیگری که جایگزین آن می شود با محتوای مشابه تهیه شده است.

4. در مراحل 2.1 "مطالعه شی" و 2.2 "انجام کار تحقیقاتی لازم"، سازمان توسعه دهنده مطالعه دقیقی از شی اتوماسیون و کار تحقیقاتی لازم (R&D) مربوط به یافتن راه ها و ارزیابی امکان انجام می دهد. اجرای الزامات کاربر، تهیه و تایید گزارشات مربوط به تحقیقات.

5. در مرحله 2.3 "توسعه گزینه هایی برای مفهوم AU و انتخاب نسخه ای از مفهوم AU که نیازهای کاربر را برآورده می کند"، در حالت کلی، گزینه های جایگزین برای مفهوم AU ایجاد شده و برنامه هایی برای اجرای آنها ایجاد کنید. ; ارزیابی منابع لازم برای اجرا و نگهداری آنها؛ ارزیابی مزایا و معایب هر گزینه؛ مقایسه نیازهای کاربر و ویژگی های سیستم پیشنهادی و انتخاب بهترین گزینه; تعیین روش برای ارزیابی کیفیت و شرایط پذیرش سیستم؛ ارزیابی اثرات دریافتی از سیستم

6. در مرحله 2.4 "گزارش کار انجام شده" گزارشی حاوی شرح کار انجام شده در مرحله، شرح و توجیه نسخه پیشنهادی مفهوم سیستم تهیه و تنظیم کنید.

7. در مرحله 3.1 "توسعه و تصویب شرایط مرجع برای ایجاد NPP"، توسعه، اجرا، هماهنگی و تصویب شرایط مرجع برای NPP و در صورت لزوم، شرایط برای بخشی از NPP. NPP انجام می شود.

8. در مرحله 4.1 "توسعه راه حل های طراحی اولیه برای سیستم و قطعات آن" تعیین می کند: عملکردهای AU. عملکردهای زیرسیستم ها، اهداف و اثرات آنها؛ ترکیب مجموعه وظایف و وظایف فردی؛ مفهوم پایگاه اطلاعاتی، ساختار بزرگ آن؛ توابع سیستم مدیریت پایگاه داده؛ ترکیب سیستم محاسباتی؛ توابع و پارامترهای نرم افزار اصلی

9. در مرحله 5.1 "توسعه راه حل های طراحی برای سیستم و قطعات آن" ارائه راه حل های کلی برای سیستم و قطعات آن، ساختار عملکردی و الگوریتمی سیستم، عملکرد پرسنل و ساختار سازمانی، ساختار ابزارهای فنی، الگوریتم‌های حل مسائل و زبان‌های مورد استفاده، سازماندهی و نگهداری پایگاه اطلاعاتی، سیستم طبقه‌بندی و کدگذاری اطلاعات، روی نرم‌افزار.

10. در مراحل 4.2 و 5.2 "توسعه مستندات برای NPP و قطعات آن"، توسعه، اجرا، موافقت و تایید اسناد تا حد لازم برای توصیف مجموعه کامل راه حل های طراحی اتخاذ شده و کافی برای کار بیشتر انجام می شود. در مورد ایجاد NPP انواع اسناد - طبق GOST 34.201.

11. در مرحله 5.3 "توسعه و اجرای مستندات برای تامین محصولات برای تکمیل NPP و (یا) الزامات فنی (مشخصات فنی) برای توسعه آنها" تهیه و اجرای مستندات برای عرضه محصولات برای تکمیل NPP. تعیین الزامات فنی و تهیه مشخصات فنی برای توسعه محصولاتی که به تولید انبوه نمی رسند.

12. در مرحله 5.4 "توسعه تکالیف طراحی در بخش های مجاور پروژه اتوماسیون" توسعه، اجرا، هماهنگی و تایید تکالیف طراحی را در قسمت های مجاور شی اتوماسیون برای ساخت و ساز، برق، بهداشتی و سایر کارهای مقدماتی مربوط به انجام دهید. ایجاد AC.

13. در مرحله 6.1 "توسعه اسناد کاری برای سیستم و قطعات آن"، اسناد کاری تهیه می شود که حاوی تمام اطلاعات لازم و کافی برای اطمینان از عملکرد کار در راه اندازی NPP و عملکرد آن و همچنین حفظ و نگهداری است. سطح ویژگی های عملیاتی (کیفیت) سیستم مطابق با تصمیمات طراحی اتخاذ شده، ثبت، هماهنگی و تایید آن. انواع اسناد - طبق GOST 34.201.

14. در مرحله 6.2 "توسعه یا انطباق برنامه ها"، برنامه ها و نرم افزارهای سیستم توسعه می یابند، انتخاب، انطباق و (یا) اتصال نرم افزار خریداری شده، توسعه اسناد نرم افزار مطابق با GOST 19.101.

15. در مرحله 7.1 "آماده سازی شی اتوماسیون برای راه اندازی NPP" کار بر روی آماده سازی سازمانی شی اتوماسیون برای راه اندازی NPP انجام می شود، از جمله: اجرای راه حل های طراحی برای ساختار سازمانی NPP. ارائه زیرمجموعه های موضوع مدیریت با مواد آموزشی و روش شناختی؛ معرفی طبقه بندی کننده های اطلاعات

16. در مرحله 7.2 "آموزش پرسنل"، پرسنل آموزش می بینند و توانایی آنها برای اطمینان از عملکرد NPP آزمایش می شود.

17. در مرحله "تکمیل AU با محصولات عرضه شده" از دریافت قطعات، مواد و محصولات مونتاژ سریال و واحد تولید اطمینان حاصل کنید. آنها کنترل کیفیت ورودی را انجام می دهند.

18. در مرحله 7.4 "کارهای ساخت و ساز و نصب" موارد زیر انجام می شود: اجرای کار در ساخت ساختمان های تخصصی (امکان) برای استقرار تجهیزات فنی و پرسنل NPP. ساخت کانال های کابلی؛ اجرای کار نصب وسایل فنی و خطوط ارتباطی؛ تست تجهیزات فنی نصب شده؛ تحویل وسایل فنی برای راه اندازی.

19. در مرحله 7.5 "راه اندازی" تنظیم مستقل سخت افزار و نرم افزار، بارگیری اطلاعات در پایگاه داده و بررسی سیستم برای نگهداری آن انجام می شود. تنظیم پیچیده همه وسایل سیستم

20. در مرحله 7.6 "آزمون های اولیه" انجام دهید:

• آزمایش نیروگاه هسته ای برای عملکرد و انطباق با شرایط مرجع مطابق با برنامه و روش آزمایش های اولیه.
• رفع نقص و اصلاحات در اسناد NPP، از جمله عملیاتی مطابق با گزارش آزمایش.
• ثبت گواهی پذیرش نیروگاه هسته ای برای بهره برداری آزمایشی.

21. در مرحله 7.7 "عملیات آزمایشی"، عملیات آزمایشی NPP انجام می شود. تجزیه و تحلیل نتایج عملیات آزمایشی NPP؛ تجدید نظر (در صورت لزوم) نرم افزار AC؛ تنظیم اضافی (در صورت لزوم) وسایل فنی نیروگاه هسته ای. ثبت گواهی پایان عملیات آزمایشی.

22. در مرحله 7.8 "آزمون های پذیرش" انجام دهید:

• تست های انطباق با شرایط مرجع مطابق با برنامه و روش های آزمون های پذیرش؛
• تجزیه و تحلیل نتایج آزمایشات AU و رفع کاستی های شناسایی شده در طول آزمایش.
• ثبت گواهی پذیرش نیروگاه هسته ای برای بهره برداری دائم.

23. در مرحله 8.1 "انجام کار مطابق با تعهدات گارانتی"، کار برای رفع نواقص شناسایی شده در حین کار NPP در دوره های گارانتی تعیین شده انجام می شود تا تغییرات لازم در اسناد NPP ایجاد شود.

24. در مرحله 8.2 "خدمات پس از گارانتی" کار در موارد زیر انجام می شود:

• تجزیه و تحلیل عملکرد سیستم؛
• شناسایی انحرافات ویژگی های عملیاتی واقعی NPP از مقادیر طراحی.
• تعیین دلایل این انحرافات؛
• رفع کمبودهای شناسایی شده و اطمینان از ثبات ویژگی های عملیاتی NPP.
• ایجاد تغییرات لازم در اسناد AU.

ضمیمه 2. مرجع

فهرست سازمان های شرکت کننده در کار ایجاد AU

1. سازمان-مشتری (کاربر) که NPP برای آن ایجاد می شود و تأمین مالی، پذیرش کار و بهره برداری از NPP و همچنین انجام کارهای فردی برای ایجاد NPP را فراهم می کند.

2. سازمان-توسعه دهنده ای که کار ایجاد AU را انجام می دهد و مجموعه ای از خدمات علمی و فنی را در مراحل و مراحل مختلف ایجاد به مشتری ارائه می دهد و همچنین نرم افزار و سخت افزارهای مختلف را برای اتحادیه AU توسعه و عرضه می کند. .

3. سازمان تامین کننده ای که به درخواست توسعه دهنده یا مشتری نرم افزار و سخت افزار را تولید و عرضه می کند.

4. سازمان-طراح عمومی شی اتوماسیون.

5. سازمان ها - طراحان بخش های مختلف پروژه شی اتوماسیون برای انجام کارهای ساختمانی، برقی، بهداشتی و سایر کارهای مقدماتی مربوط به ایجاد نیروگاه هسته ای.

6. سازمان برای ساخت و ساز، مونتاژ، راه اندازی و غیره.

یادداشت:

1. بسته به شرایط ایجاد یک AU، ترکیبات مختلفی از عملکردهای یک مشتری، یک توسعه دهنده، یک تامین کننده و سایر سازمان های دخیل در ایجاد یک AU امکان پذیر است.

2. مراحل و مراحل کار آنها در ایجاد AU بر اساس این استاندارد تعیین می شود.

داده های اطلاعاتی

1. توسعه و معرفی شده توسط کمیته دولتی اتحاد جماهیر شوروی برای مدیریت کیفیت محصول و استانداردها

توسعه دهندگان

یو.خ. ورمیشف، دکتر. علوم; Ya.G. ویلنچیک؛ در و. وروپاف، دکتر. علوم; L.M. سیدنبرگ، کند. فن آوری علوم; یو.بی. ایرز، کند. فن آوری علوم; V.D. کوستیوکوف، کاند. فن آوری علوم; M.A. لابوتین، باند. فن آوری علوم; N.P. لسکوفسکایا؛ است. میتیایف؛ V.F. پوپوف (رهبر موضوع)؛ S.V. گرشینا; A.I. ناشنوایان؛ جنوب. Zhukov، Cand. Tech. علوم; ز.پ. زادوبوفسکایا؛ V.G. ایوانف؛ یو.آی. Karavanov، Cand. Tech. علوم; A.A. پاره شده؛ V.Yu. کورولف; در و. ماخناچ، کند. فن آوری علوم; S. B. میخالف، دکتر. علوم; V.N. پتریکیویچ؛ V.A. رحمانوف، کند. اقتصاد علوم; A.A. راتکوویچ؛ R.S. سدگف، دکتر. علوم; N.V. استپانچیکووا؛ خانم. سوروتس; A.V. فلنتز L.O. خویلفسکی، کند. فن آوری علوم; VC. چیستوف، کند. اقتصاد علوم

2. تصویب شده و وارد عمل شده توسط فرمان کمیته دولتی اتحاد جماهیر شوروی در مورد مدیریت کیفیت محصول و استانداردهای مورخ 29 دسامبر 1990 شماره 3469

معرفی

V دنیای مدرنهر روز ده ها و صدها نفر ظاهر می شوند برنامه های مختلف، برنامه های کاربردی، سیستم های اطلاعاتی. آنها می توانند برای بخش عمومی یا تجاری و همچنین برای کاربران عمومی طراحی شوند. 90٪ از همه کاربران مستندات را نمی خوانند، آن را خسته کننده، کسل کننده و غیر جالب می دانند و تنها زمانی که چیزی درست نمی شود یا کاملاً غیرممکن است که بدون دستورالعمل به آن پی ببرید، کتابچه راهنمای کاربر را باز می کند. اکنون به طور کلی پذیرفته شده است که رابط کاربری را به گونه ای بسازید که بصری باشد و کاربر بتواند بدون نیاز به خواندن کتابچه راهنمای طولانی، سیستم را کشف کند. با این حال، هنگام کار با مشتریان بزرگ، تقریباً همیشه لازم است بسته خاصی از اسناد - کتابچه راهنمای کاربر، دستورالعمل، راه حل های طراحی تهیه شده مطابق با GOST ارائه شود.
هنگامی که برای اولین بار با نوشتن اسناد مطابق با GOST مواجه می شوید، دچار گیجی و شوک کامل می شوید، زیرا این GOST ها "دریا" هستند و نحوه و نحوه نوشتن در مورد آنها نامشخص می شود.
این مقاله GOST ها برای نوشتن اسناد و نکات اصلی آنها را مورد بحث قرار می دهد.

GOST ها چیست؟

ابتدا باید بفهمید که GOST چیست. همه می دانند که GOST چیزی است که تحت اتحادیه توسعه یافته است و تعداد آنها به سادگی بی نهایت است. من عجله می کنم تا به شما اطمینان دهم که استانداردهای GOST زیادی برای بخش فناوری اطلاعات وجود ندارد و همه آنها علیرغم زمان ایجادشان، ارتباط خود را از دست نداده اند.
اول از همه، استانداردهای نوشتن اسناد به دو نوع تقسیم می شوند:

1. استانداردهای بین المللی (ISO، IEEE Std)؛
2. GOST های روسی یا شوروی.

استانداردهای بین المللی
استانداردهای بین المللی برای توسعه اسناد در سطح بین المللی استفاده می شود. به عنوان یک قاعده، آنها رایگان نیستند، زیرا توسط سازمان های دولتی توسعه نمی یابند، اما، برخلاف ما، اخیراً توسعه یافته اند. موضوع استانداردهای بین المللی بسیار گسترده است، بنابراین در مقاله دیگری به آن پرداخته خواهد شد. چندین استاندارد فوراً مورد بررسی قرار می گیرند که ارتباط نزدیکی با نوشتن اسناد دارند.
لیست استانداردهای اصلی بین المللی برای نوشتن اسناد:

1. IEEE Std 1063-2001 "IEEE Standard for Software User Documentation" - استانداردی برای نوشتن کتابچه راهنمای کاربر.
2. IEEE Std 1016-1998 "عمل توصیه شده IEEE برای توضیحات طراحی نرم افزار" - استانداردی برای نوشتن اطلاعات فنیبرنامه ها؛
3. ISO / IEC FDIS 18019: 2004 "راهنماها برایطراحی و تهیه مستندات کاربر برای نرم افزار کاربردی ” استاندارد دیگری برای نوشتن کتابچه راهنمای کاربر است. این سند دارد تعداد زیادی ازمثال ها. یعنی بیشتر شبیه کتابچه راهنمای نوشتن کتابچه راهنمای کاربر است. مبتدیان به ویژه مفید خواهند بود.
4. ISO / IEC 26514: 2008، الزامات طراحان و توسعه دهندگان مستندات کاربر، استاندارد دیگری برای طراحان و توسعه دهندگان مستندات کاربر است.

در واقع، استانداردهای بین المللی زیادی وجود دارد و در هر کشوری متفاوت است، زیرا ممکن است یک استاندارد همیشه برای شرکت های اروپایی و آسیایی مناسب نباشد.

استانداردهای روسیه
استانداردهای روسیه در سطح ایالتی توسعه یافته است. همه آنها کاملا رایگان هستند و پیدا کردن همه آنها در اینترنت آسان است. برای نوشتن مستندات برنامه از دو سری GOST 19 و 34 استفاده می شود که در مورد آنها بیشتر بحث خواهد شد.

تفاوت بین GOST های سری 19 و 34 چیست؟

اولین سوالی که مطرح می شود این است که به طور کلی این GOST های 19 و 34 چگونه با یکدیگر متفاوت هستند.
در GOST 19.781-90 "سیستم یکپارچه اسناد برنامه. نرم افزار سیستم های پردازش اطلاعات اصطلاحات و تعاریف "تعاریف نشان داده شده است:

1. برنامه - داده های در نظر گرفته شده برای کنترل اجزای خاص یک سیستم پردازش اطلاعات به منظور پیاده سازی یک الگوریتم خاص.
2. نرم افزار - مجموعه ای از برنامه های سیستم پردازش اطلاعات و اسناد برنامه لازم برای عملکرد این برنامه ها.

در GOST 34.003-90 "فناوری اطلاعات. مجموعه ای از استانداردها برای سیستم های خودکار. سیستم های خودکار اصطلاحات و تعاریف "تعریف نشان داده شده است:

1. سیستم خودکار (AS) سیستمی متشکل از پرسنل و مجموعه ای از وسایل برای خودکارسازی فعالیت های آنهاست که فناوری اطلاعات را برای انجام وظایف تعیین شده پیاده سازی می کند.
   بسته به نوع فعالیت، به عنوان مثال، انواع زیر از AU متمایز می شود: سیستم های کنترل خودکار (ACS)، سیستم ها طراحی به کمک کامپیوتر(CAD)، سیستم های تحقیقاتی خودکار (ASNI) و دیگران.

بسته به نوع شیء کنترل شده (فرآیند)، ACS به عنوان مثال به: ACS توسط فرآیندهای تکنولوژیکی (ACS)، ACS توسط شرکت ها (ACS) و غیره تقسیم می شود.
همچنین، GOST 34 به انواع پشتیبانی NPP تقسیم می شود:

1. سازمانی؛
2. روشمند؛
3. فنی؛
4. ریاضی؛
5. نرم افزار؛
6. اطلاعاتی؛
7. وابسته به زبانشناسی؛
8. مجاز؛
9. ارگونومیک.

در نتیجه، سیستم خودکار یک برنامه نیست، بلکه مجموعه ای از انواع پشتیبانی از جمله نرم افزار است. AS، به عنوان یک قاعده، یک راه حل سازمانی برای یک کاربر و مشتری خاص دارد و برنامه را می توان برای تعداد زیادی از کاربران ایجاد و تکرار کرد بدون اینکه به هیچ سازمانی وابسته باشد.
بنابراین، اگر در حال توسعه اسناد برای برنامه‌ای هستید که برای یک شرکت خاص ایجاد کرده‌اید، GOST 34 شماست. اگر در حال نوشتن اسناد برای یک برنامه انبوه هستید، GOST 19 شما.

GOST 34

سری GOST 34 (GOST 34.xxx استانداردهای فناوری اطلاعات) شامل موارد زیر است:

1. GOST 34.201-89 انواع، کامل بودن و نامگذاری اسناد هنگام ایجاد سیستم های خودکار - این استاندارد انواع، نام، کامل بودن و تعداد اسناد را تعیین می کند. این یکی از اسناد اصلی در سری GOST 34 است. در واقع، این یک سند اساسی است، بنابراین مبتدیان باید ابتدا با آن آشنا شوند.
2. GOST 34.320-96 مفاهیم و اصطلاحات برای یک طرح مفهومی و پایگاه اطلاعاتی - این استاندارد مفاهیم و اصطلاحات اساسی طرح‌های مفهومی و پایگاه‌های اطلاعاتی را ایجاد می‌کند که توسعه، توصیف و کاربرد طرح‌های مفهومی و پایگاه‌های اطلاعاتی، دستکاری اطلاعات و همچنین را پوشش می‌دهد. شرح و اجرای فرآیند اطلاعات استاندارد نقش طرح واره مفهومی را تعریف می کند. مفاد ذکر شده در آن ماهیت مشاوره ای دارند و می توانند برای ارزیابی سیستم های مدیریت پایگاه داده (DBMS) استفاده شوند. این سند روش های خاصی را برای استفاده از ابزارهای پشتیبانی طرحواره مفهومی توصیف نمی کند. زبان های طرح واره مفهومی توصیف شده در استاندارد نباید استاندارد در نظر گرفته شوند.
3. GOST 34.321-96 فناوری اطلاعات. سیستم استاندارد پایگاه داده مدل مرجع مدیریت - این سند یک مدل مرجع مدیریت داده را ایجاد می کند.
   مدل مرجع اصطلاحات و مفاهیم کلی مربوط به داده های سیستم های اطلاعاتی را تعریف می کند. چنین مفاهیمی برای تعریف خدمات ارائه شده توسط سیستم های مدیریت پایگاه داده یا سیستم های فرهنگ لغت داده استفاده می شود.
   مدل مرجع پروتکل هایی را برای مدیریت داده ها در نظر نمی گیرد.
   دامنه مدل مرجع شامل فرآیندهایی است که به مدیریت داده های پایدار و تعامل آنها با فرآیندهایی که با الزامات یک خاص متفاوت است، مربوط می شود. سیستم اطلاعاتو همچنین خدمات کلی مدیریت داده برای تعریف، ذخیره، جستجو، به روز رسانی، ورود، کپی، بازیابی و انتقال داده ها.
4. GOST 34.601-90 سیستم های خودکار. مراحل ایجاد - استاندارد مراحل و مراحل ایجاد یک AU را تعیین می کند.
5. GOST 34.602-89 شرایط مرجع برای ایجاد یک سیستم خودکار (به جای GOST 24.201-85) - ترکیب، محتوا، قوانین تنظیم سند "شرایط مرجع برای ایجاد (توسعه یا نوسازی) سیستم را تعیین می کند. "
   این سند یکی از پرکاربردترین اسناد سری GOST 34 است. هنگام توسعه TK طبق این GOST، باید سایر استانداردها را به خاطر بسپارید، حتی اگر این سند حاوی ارجاعاتی به این استانداردها نباشد.
6. GOST 34.603-92 فناوری اطلاعات. انواع تست های سیستم های خودکار - استاندارد انواع تست های AU (خودکار، یکپارچه، تست های پذیرش و عملیات آزمایشی) و الزامات کلی برای انجام آنها را تعیین می کند.
7. RD 50-34.698-90 سیستم های خودکار. الزامات محتوای اسناد یکی از مهمترین اسناد 34 GOST است، زیرا در آن است که محتوای تقریباً تمام اسناد و همچنین شرح هر پاراگراف سند شرح داده شده است.
8. GOST R ISO / IEC 8824-3-2002 فناوری اطلاعات. نماد نحوی انتزاعی نسخه اول - این استاندارد بین‌المللی بخشی از نماد نحوی انتزاعی 1 (ASN.1) است و یک نماد برای تعیین محدودیت‌های تعریف شده توسط کاربر و محدودیت‌های جدول ارائه می‌کند.
9. GOST R ISO / IEC 10746-3-2001 مدیریت داده و پردازش توزیع شده باز.
   در این استاندارد:
   • مشخص می شود که چگونه سیستم های پردازش توزیع شده باز (ODP) با استفاده از مفاهیم معرفی شده در GOST R ISO / IEC 10746-2 مشخص می شوند.
   • ویژگی هایی که توسط آن سیستم ها به عنوان سیستم های ODP طبقه بندی می شوند مشخص می شوند.

   این استاندارد چارچوبی را برای هماهنگی توسعه استانداردها برای سیستم های ODP ایجاد می کند.

10. GOST R ISO / IEC 15271-02 فرآیندهای چرخه عمر نرم افزار - به نظر من، این GOST برای تحلیلگران در طراحی و مدل سازی نیروگاه های هسته ای بیشتر مورد نیاز است.
    این سند، از دیدگاه من، برای اهداف صرفاً آموزشی مفید است.
11. GOST R ISO / IEC 15910-2002 فرآیند ایجاد اسناد کاربر برای یک ابزار نرم افزاری - حداقل فرآیند مورد نیاز برای ایجاد اسناد کاربر از همه نوع را برای یک ابزار نرم افزاری که دارای رابط کاربری است، تعریف می کند. این نماها اسناد چاپی (به عنوان مثال، راهنمای کاربر و کارت های مرجع سریع)، اسناد تعاملی (عملیاتی)، متن راهنما ("راهنما") و سیستم های اسناد تعاملی را پوشش می دهند.

بنابراین، بر اساس همه چیزهایی که در بالا نوشته شده است، واضح است که اسناد اصلی در 34 GOST 3: GOST 34.201-89، RD 50-34.698-90 و GOST 34.602-89.
هنگام تهیه بسته ای از اسناد، ابتدا باید GOST 34.201-89 را باز کنید و مرحله ایجاد طراحی پیش نویس، طراحی فنی و مستندات کاری را انتخاب کنید. در مرحله بعد، باید اسنادی را برای توسعه انتخاب کنید که با مرحله ایجاد مطابقت دارند.

فهرست اسناد 34 GOST

صحنه ایجاد	عنوان سند	کد	قسمت پروژه	پریناد بستر به پروژه اما برآورد بارانداز نوح پلیس یون ها	پریناد بستر به بهره برداری استفاده از نوح بالا کیومن استفاده از	دستورالعمل های اضافی
EP	برگه طرح شماتیک	EP *	یا	—	—	—
	یادداشت توضیحی به طرح پیش نویس	P1	یا	—	—	—
EP، TP	چارت سازمانی	CO	یا	—	—	گنجاندن در سند P3 یا PV مجاز است
	طرح ساختاری مجتمع وسایل فنی	C1 *	سپس	NS	—
	نمودار ساختار عملکردی	C2 *	یا	—	—	هنگام توسعه اسناد CO، C1، C2، C3 در مرحله ES، مجاز است آنها را در سند P1 گنجانده شود.
	تخصصی (جدید) وسایل فنی	ساعت 9	سپس	NS	—	هنگام توسعه در مرحله TP مجاز به گنجاندن به سند P2
	طرح اتوماسیون	C3 *	سپس	NS	—	—
	شرایط مرجع برای توسعه تخصصی (جدید) وسایل فنی	—	سپس	—	—	پروژه شامل نمی شود
TP	تکالیف توسعه بهداشتی و بخش های دیگر مربوط به پروژه با ایجاد سیستم	—	سپس	NS	—	پروژه شامل نمی شود
	برگه پروژه فنی	TP *	یا	—	—	—
	لیست محصولات خریداری شده	معاون *	یا	—	—	—
	لیست سیگنال های ورودی و داده ها	در 1	و در مورد	—	—	—
	لیست سیگنال های خروجی (اسناد)	در 2	و در مورد	—	—	—
	لیست وظایف توسعه ساختمانی، برقی، بهداشتی و بخش های دیگر مربوط به پروژه با ایجاد سیستم	در ساعت 3	سپس	NS	—	در سند P2 مجاز است
	یادداشت توضیحی به پروژه فنی	P2	یا	—	—	شامل برنامه اقدام برای آماده سازی شی برای راه اندازی سیستم های در حال بهره برداری
	شرح خودکار کارکرد	P3	یا	—	—	—
	شرح تنظیمات کار (مجموعه وظایف)	P4	یا	—	—	مجاز است شامل شود به اسناد P2 یا P3
	شرح اطلاعات پشتیبانی سیستم	P5	و در مورد	—	—	—
	شرح سازمان پایگاه اطلاع رسانی	P6	و در مورد	—	—	—
TP	شرح سیستم های طبقه بندی و کد نویسی	P7	و در مورد	—	—	—
	توضیحات آرایه اطلاعات	P8	و در مورد	—	—	—
	توضیحات مجتمع وسایل فنی	P9	سپس	—	—	برای این کار، طبق GOST 19.101 مجاز است در سند 46 گنجانده شود
	توضیحات نرم افزار ایمن سازی	PA	بر	—	—	—
	توضیحات الگوریتم (رویه طراحی)	PB	MO	—	—	مجاز است در اسناد P2، P3 یا P4 گنجانده شود
	شرح سازمانی سازه های	PV	OO	—	—	—
	طرح چیدمان	C8	سپس	NS	—	در سند P9 مجاز است
	لیست تجهیزات و مواد	—	سپس	NS	—	—
	محاسبه برآورد محلی	B2	یا	NS	—	—
TP، RD	ارزیابی پروژه قابلیت اطمینان سیستم	B1	یا	—	—	—
	ترسیم فرم سند (قاب ویدئو)	C9	و در مورد	—	NS	در مرحله TP مجاز است در اسناد گنجانده شود P4 یا P5
RD	لیست دارندگان اصل	DP *	یا	—	—	—
	بیانیه عملیاتی اسناد	ED *	یا	—	NS	—
	مشخصات سخت افزاری	در ساعت 4	سپس	NS	—	—
	بیانیه مورد نیاز در مواد	ساعت 5	سپس	NS	—	—
	فهرست رسانه های ماشینی اطلاعات	VM *	و در مورد	—	NS	—
	آرایه داده های ورودی	ساعت 6	و در مورد	—	NS	—
RD	دایرکتوری پایگاه داده	در ساعت 7	و در مورد	—	NS	—
	ترکیب خروجی (پیام ها)	ساعت 8	و در مورد	—	NS	—
	برآوردهای محلی	B3	یا	NS	—	—
	روش (تکنولوژی) خودکار طراحی	I1	OO	—	NS	—
	دستورالعمل فن آوری	و 2	OO	—	NS	—
	راهنمای کاربر	I3	OO	—	NS	—
	دستورالعمل شکل دهی و نگهداری پایگاه داده (مجموعه داده)	I4	و در مورد	—	NS	—
	دستورالعمل های عملیاتی برای KTS	IE	سپس	—	NS	—
	نمودار اتصال سیم کشی خارجی	C4 *	سپس	NS	—	مجاز به اجرا در در قالب جداول
	نمودار اتصال سیم کشی خارجی	C5 *	سپس	NS	—	همچنین
	جدول اتصال و اتصال	C6	سپس	NS	—	—
	نمودار تقسیم سیستم (ساختاری)	E1 *	سپس	—	—	—
	نقاشی منظم	که در*	سپس	NS	—	—
	نقشه نصب تجهیزات فنی	CA	سپس	NS	—	—
	نمودار شماتیک	نشست	سپس	NS	—	—
	طرح ساختاری مجتمع وسایل فنی	C1 *	سپس	NS	—	—
	چیدمان تجهیزات و سیم کشی	C7	سپس	NS	—	—
	شرح فن آوری فرآیند پردازش داده ها (از جمله پردازش از راه دور)	PG	OO	—	NS	—
	توضیحات کلی سیستم	PD	یا	—	NS	—
	برنامه و روش آزمون (اجزا، سیستم های اتوماسیون، زیرسیستم ها، سیستم های)	PM *	یا	—	—	—
	فرم	FD *	یا	—	NS	—
	گذرنامه	PS *	یا	—	NS	—
* اسنادی که کد آنها مطابق با الزامات استاندارد ESKD تنظیم شده است

توجه به جدول:

1. جدول از عناوین زیر استفاده می کند:
   • EP - طراحی اولیه؛
   • TP - طراحی فنی؛
   • RD - اسناد کاری؛
   • OR - راه حل های گسترده سیستم؛
   • OO - تصمیم گیری در مورد پشتیبانی سازمانی؛
   • TO - راه حل هایی برای پشتیبانی فنی؛
   • IO - راه حل هایی برای پشتیبانی اطلاعات؛
   • نرم افزار - راه حل های نرم افزاری؛
   • MO - راه حل های نرم افزاری.
2. علامت X - نشان دهنده متعلق به برآوردهای طراحی یا اسناد عملیاتی است.
3. نامگذاری اسناد یک نام بسته به تصمیمات طراحی اتخاذ شده در هنگام ایجاد سیستم ایجاد می شود.

هنگامی که لیست اسناد مشخص شد، در RD 50-34.698-90 باید اسناد انتخاب شده را پیدا کنید و آنها را دقیقاً مطابق با نکات ذکر شده توسعه دهید. تمام نکات محتوایی که نشان داده شده است باید در سند باشد.
اگر شرایط مرجع در حال توسعه است، بلافاصله باید GOST 34.602-89 را باز کنید و مشخصات فنی را دقیقاً طبق پاراگراف ها ایجاد کنید.

GOST 19

سری GOST 19 (GOST 19.xxx The Unified Programming Documentation System (ESPD)) شامل موارد زیر است:

1. 1. GOST 19.001-77 مقررات عمومی - بیش از حد سند مشترک، کاربرد عملی ندارد. بنابراین، می توانید از آن صرف نظر کنید.
   2. GOST 19781-90 شرایط و تعاریف - لیست خوبتعاریف در زمینه نرم افزار برای سیستم های پردازش اطلاعات. به جز به عنوان تعاریف، چیز دیگری شامل نمی شود.
   3. GOST 19.101-77 انواع برنامه ها و اسناد برنامه - یکی از اسناد اصلی 19 GOST. با او است که باید با 19 GOST شروع به کار کنید، زیرا حاوی لیست کامل و نامگذاری اسناد GOST است.

فهرست اسناد 19 GOST

کد	نوع سند	مراحل توسعه
		طرح پروژه	فنی پروژه	پیش نویس کاری
				جزء	مجتمع
—	مشخصات	—	—
05	لیست دارندگان اصلی	—	—	—
12	متن برنامه	—	—
13	توضیحات برنامه	—	—
20	بیانیه اسناد عملیاتی	—	—
30	فرم	—	—
31	توضیحات برنامه	—	—
32	راهنمای برنامه نویس سیستم	—	—
33	راهنمای برنامه نویس	—	—
34	راهنمای اپراتور	—	—
35	توضیحات زبان	—	—
46	راهنمای فنی نگهداری	—	—
51	برنامه و روش آزمون	—	—
81	یادداشت توضیحی			—	—
90-99	اسناد دیگر

افسانه:
- سند واجب است؛
- سند برای اجزایی که کاربرد مستقل دارند اجباری است.
- نیاز به تنظیم سند در مرحله توسعه و تأیید شرایط مرجع تعیین می شود.
- - سند تنظیم نشده است.

1. GOST 19.102-77 مراحل توسعه - شامل شرح مراحل توسعه است. برای اهداف آموزشی مفید است. به نظر من فایده عملی خاصی ندارد.
2. GOST 19.103-77 تعیین برنامه ها و اسناد برنامه - شامل شرحی از انتساب یک شماره (کد) به یک سند است. حتی پس از خواندن این GOST، تعداد زیادی سؤال در مورد نحوه اختصاص این شماره به یک سند باقی می ماند.
3. GOST 19.104-78 کتیبه های اساسی - بدون توجه به نحوه اجرای آنها، فرم ها، اندازه ها، مکان و روش پر کردن کتیبه های اصلی برگه تأیید و صفحه عنوان را در اسناد برنامه ارائه شده توسط استانداردهای ESDM تعیین می کند. از آنجایی که اسناد 19 GOST در قاب ها تنظیم شده است، این سند بسیار مهم است.
4. GOST 19.105-78 الزامات عمومی برای اسناد برنامه - الزامات عمومی را برای طراحی اسناد برنامه تعیین می کند. الزامات خیلی کلی هستند. به عنوان یک قاعده، این GOST تقریباً هرگز برای توسعه یک سند استفاده نمی شود، زیرا GOST ویژه کافی برای یک سند وجود دارد، اما برای دانش عمومی در این GOST هنوز بهتر است یک بار نگاه کنید.
5. GOST 19.106-78 الزامات برای اسناد برنامه اجرا شده در حال چاپ- شامل الزامات طراحی تمام اسناد 19 GOST است.
6. GOST 19.201-78 شرایط مرجع، الزامات محتوا و طراحی - روش ساخت و اجرای مشخصات فنی برای توسعه یک برنامه یا محصول نرم افزاری را تعیین می کند.

   بندهای TK 34 GOST و 19 GOST متفاوت هستند.

7. GOST 19.601-78 قوانین کلی برای تکرار، حسابداری و ذخیره سازی - قوانین عمومیتکثیر، گردش، حسابداری و ذخیره اسناد برنامه. در GOST، در چندین پاراگراف، نحوه اطمینان از گم نشدن اسناد توضیح داده شده است.
8. GOST 19.602-78 قوانین برای تکثیر، حسابداری و ذخیره اسناد برنامه، چاپ کامل. به نوعی - افزودنی به GOST 19.601-78.
9. GOST 19.603-78 قوانین کلی برای ایجاد تغییرات - قوانین کلی برای ایجاد تغییرات در اسناد برنامه ایجاد می کند. در اصل، یک الگوریتم بوروکراتیک طولانی را برای ایجاد تغییرات در اسناد توصیف می کند.
10. قوانین GOST 19.604-78 برای ایجاد تغییرات در اسناد برنامه به روش چاپی - روش کار و پر کردن برگه ثبت تغییر از فهرست را شرح می دهد.

فهرستی از GOST های تخصصی، یعنی هر یک از آنها محتوا و الزامات یک سند خاص را شرح می دهد:

1. مشخصات GOST 19.202-78. الزامات محتوا و طراحی؛
2. GOST 19.301-79 برنامه و روش آزمایش. الزامات محتوا و طراحی؛
3. متن برنامه GOST 19.401-78. الزامات محتوا و طراحی؛
4. GOST 19.402-78 شرح برنامه؛
5. GOST 19.403-79 فهرست دارندگان اصلی؛
6. GOST 19.404-79 یادداشت توضیحی. الزامات محتوا و طراحی؛
7. فرم GOST 19.501-78. الزامات محتوا و طراحی؛
8. GOST 19.502-78 شرح برنامه. الزامات محتوا و طراحی؛
9. راهنمای برنامه نویس سیستم GOST 19.503-79. الزامات محتوا و طراحی؛
10. راهنمای برنامه نویس GOST 19.504-79. الزامات محتوا و طراحی؛
11. راهنمای اپراتور GOST 19.505-79. الزامات محتوا و طراحی؛
12. GOST 19.506-79 شرح زبان. الزامات محتوا و طراحی؛
13. GOST 19.507-79 بیانیه اسناد عملیاتی؛
14. راهنمای تعمیر و نگهداری GOST 19.508-79. الزامات محتوا و طراحی

روش کار با 19 GOST:

1. در GOST 19.101-77، یک سند و کد آن را با توجه به مرحله توسعه انتخاب کنید.
2. طبق GOST 19.103-77، شماره ای را به سند اختصاص دهید.
3. سپس، مطابق با GOST 19.104-78 و 19.106-78، یک سند تهیه کنید.
4. از لیست تخصصی GOST ها، باید موردی را انتخاب کنید که با سند در حال توسعه مطابقت دارد.

نتیجه

GOST ترسناک و آسان نیست! نکته اصلی این است که بفهمیم چه چیزی باید نوشته شود و از چه GOST برای این کار استفاده می شود. GOST های اصلی 19 و 34 ما برای نوشتن اسناد بسیار قدیمی هستند، اما هنوز هم تا به امروز مرتبط هستند. نوشتن مستندات مطابق با استاندارد بسیاری از سوالات بین پیمانکار و مشتری را برطرف می کند. بنابراین باعث صرفه جویی در زمان و هزینه می شود.