গতিশীল সিমুলেশন প্রক্রিয়ায় TOR প্রয়োজনীয়তার স্বয়ংক্রিয় যাচাইকরণ

থিম অব্যাহত "তোমার প্রমাণ কি?", আসুন অন্য দিক থেকে গাণিতিক মডেলিংয়ের সমস্যাটি দেখি। আমরা নিশ্চিত হওয়ার পরে যে মডেলটি জীবনের হোমস্পন সত্যের সাথে মিলে যায়, আমরা মূল প্রশ্নের উত্তর দিতে পারি: "আমাদের এখানে কি আছে?" একটি প্রযুক্তিগত বস্তুর একটি মডেল তৈরি করার সময়, আমরা সাধারণত নিশ্চিত করতে চাই যে এই বস্তুটি আমাদের প্রত্যাশা পূরণ করবে। এই উদ্দেশ্যে, প্রক্রিয়াগুলির গতিশীল গণনা করা হয় এবং ফলাফলগুলি প্রয়োজনীয়তার সাথে তুলনা করা হয়। এটি একটি ডিজিটাল টুইন, একটি ভার্চুয়াল প্রোটোটাইপ ইত্যাদি। ফ্যাশনেবল shnyags যারা, ডিজাইন পর্যায়ে, আমরা যা পরিকল্পনা করেছি তা আমরা পেতে পারি কিনা তা নিশ্চিত করার সমস্যার সমাধান করে।

কিভাবে আমরা দ্রুত নিশ্চিত করতে পারি যে আমাদের সিস্টেমটি ঠিক যা আমরা ডিজাইন করি, আমাদের নকশা কি উড়বে বা ভাসবে? আর যদি উড়ে যায়, কত উঁচুতে? আর যদি ভেসে যায়, কত গভীরে?

এই নিবন্ধটি প্রযুক্তিগত সিস্টেমের গতিশীল মডেল তৈরি করার সময় একটি প্রযুক্তিগত ভবনের প্রয়োজনীয়তার সাথে সম্মতির যাচাইকরণের স্বয়ংক্রিয়তা নিয়ে আলোচনা করে। একটি উদাহরণ হিসাবে, আসুন একটি বিমান এয়ার কুলিং সিস্টেমের প্রযুক্তিগত স্পেসিফিকেশনের একটি উপাদান দেখুন।

আমরা সেই প্রয়োজনীয়তাগুলি বিবেচনা করি যা একটি নির্দিষ্ট গণনার মডেলের উপর ভিত্তি করে সংখ্যাগতভাবে প্রকাশ করা যায় এবং গাণিতিকভাবে যাচাই করা যায়। এটি স্পষ্ট যে এটি যে কোনও প্রযুক্তিগত সিস্টেমের জন্য সাধারণ প্রয়োজনীয়তার অংশ মাত্র, তবে এটি তাদের পরীক্ষা করার জন্য যে আমরা বস্তুর গতিশীল মডেল তৈরিতে সময়, স্নায়ু এবং অর্থ ব্যয় করি।

একটি নথির আকারে প্রযুক্তিগত প্রয়োজনীয়তাগুলি বর্ণনা করার সময়, বিভিন্ন ধরণের বিভিন্ন প্রয়োজনীয়তাকে আলাদা করা যেতে পারে, যার প্রত্যেকটির প্রয়োজনীয়তা পূরণের স্বয়ংক্রিয় যাচাইকরণ গঠনের জন্য বিভিন্ন পদ্ধতির প্রয়োজন।

উদাহরণস্বরূপ, প্রয়োজনীয়তার এই ছোট কিন্তু বাস্তবসম্মত সেটটি বিবেচনা করুন:

1. জল চিকিত্সা সিস্টেমের প্রবেশদ্বারে বায়ুমণ্ডলীয় বায়ু তাপমাত্রা:
   পার্কিং লটে - মাইনাস 35 থেকে 35 ºС,
   ফ্লাইটে - মাইনাস 35 থেকে 39 ºС পর্যন্ত।
2. ফ্লাইটে বায়ুমণ্ডলীয় বায়ুর স্থির চাপ 700 থেকে 1013 GPa (526 থেকে 760 mm Hg পর্যন্ত)।
3. ফ্লাইটে SVO এয়ার ইনটেকের প্রবেশপথে মোট বায়ুচাপ 754 থেকে 1200 GPa (566 থেকে 1050 mm Hg পর্যন্ত)।
4. শীতল বাতাসের তাপমাত্রা:
   পার্কিং লটে - 27 ºС এর বেশি নয়, প্রযুক্তিগত ব্লকগুলির জন্য - 29 ºС এর বেশি নয়,
   ফ্লাইটে - 25 ºС এর বেশি নয়, প্রযুক্তিগত ব্লকগুলির জন্য - 27 ºС এর বেশি নয়।
5. শীতল বায়ু প্রবাহ:
   যখন পার্ক করা হয় - কমপক্ষে 708 কেজি/ঘন্টা,
   ফ্লাইটে - 660 কেজি/ঘন্টা কম নয়।
6. যন্ত্রের বগিতে বাতাসের তাপমাত্রা 60 ºС এর বেশি নয়।
7. শীতল বাতাসে সূক্ষ্ম মুক্ত আর্দ্রতার পরিমাণ 2 গ্রাম/কেজি শুকনো বাতাসের বেশি নয়।

এমনকি প্রয়োজনীয়তার এই সীমিত সেটের মধ্যে, কমপক্ষে দুটি বিভাগ রয়েছে যা সিস্টেমে ভিন্নভাবে পরিচালনা করা প্রয়োজন:

• সিস্টেমের অপারেটিং অবস্থার জন্য প্রয়োজনীয়তা (ধারা 1-3);
• সিস্টেমের জন্য প্যারামেট্রিক প্রয়োজনীয়তা (ধারা 3-7)।

সিস্টেম অপারেটিং অবস্থার প্রয়োজনীয়তা
মডেলিংয়ের সময় বিকশিত হওয়া সিস্টেমের জন্য বাহ্যিক শর্তগুলি সীমানা শর্ত হিসাবে বা সাধারণ সিস্টেমের অপারেশনের ফলাফল হিসাবে নির্দিষ্ট করা যেতে পারে।
গতিশীল সিমুলেশনে, এটি নিশ্চিত করা প্রয়োজন যে নির্দিষ্ট অপারেটিং শর্তগুলি সিমুলেশন প্রক্রিয়া দ্বারা আচ্ছাদিত।

প্যারামেট্রিক সিস্টেমের প্রয়োজনীয়তা
এই প্রয়োজনীয়তাগুলি সিস্টেম নিজেই প্রদত্ত পরামিতি। মডেলিং প্রক্রিয়া চলাকালীন, আমরা গণনার ফলাফল হিসাবে এই পরামিতিগুলি পেতে পারি এবং নিশ্চিত করতে পারি যে প্রতিটি নির্দিষ্ট গণনায় প্রয়োজনীয়তাগুলি পূরণ করা হয়েছে।

প্রয়োজনীয়তা সনাক্তকরণ এবং কোডিং

প্রয়োজনীয়তার সাথে কাজ করার সহজতার জন্য, বিদ্যমান মানগুলি প্রতিটি প্রয়োজনীয়তার জন্য একটি শনাক্তকারী বরাদ্দ করার সুপারিশ করে। শনাক্তকারী বরাদ্দ করার সময়, একটি ইউনিফাইড কোডিং সিস্টেম ব্যবহার করা অত্যন্ত বাঞ্ছনীয়।

প্রয়োজনীয় কোডটি কেবলমাত্র একটি সংখ্যা হতে পারে যা প্রয়োজনের অর্ডার নম্বরকে প্রতিনিধিত্ব করে, অথবা এতে প্রয়োজনীয়তার ধরণের জন্য একটি কোড, সিস্টেম বা ইউনিটের জন্য একটি কোড যা এটি প্রযোজ্য, একটি প্যারামিটার কোড, একটি অবস্থান কোড এবং অন্য কিছু ইঞ্জিনিয়ার কল্পনা করতে পারেন। (এনকোডিং ব্যবহারের জন্য নিবন্ধটি দেখুন)

সারণী 1 প্রয়োজনীয় কোডিং এর একটি সহজ উদাহরণ প্রদান করে।

1. প্রয়োজনীয়তার উৎসের কোড R- প্রয়োজনীয়তা TK;
2. কোড ধরনের প্রয়োজনীয়তা E - প্রয়োজনীয়তা - পরিবেশগত পরামিতি, বা অপারেটিং শর্ত
   এস - সিস্টেম দ্বারা প্রদত্ত প্রয়োজনীয়তা;
3. এয়ারক্রাফট স্ট্যাটাস কোড 0 – যে কোন, জি – পার্ক করা, F – ফ্লাইটে;
4. শারীরিক পরামিতি টাইপ কোড T – তাপমাত্রা, P – চাপ, G – প্রবাহ হার, আর্দ্রতা H;
5. প্রয়োজনীয়তার ক্রমিক নম্বর।

ID প্রয়োজনীয়তা	বিবরণ	স্থিতিমাপ
REGT01	জল কুলিং সিস্টেমের প্রবেশদ্বারে পরিবেষ্টিত বায়ু তাপমাত্রা: পার্কিং লটে - মাইনাস 35ºС থেকে। 35 ºС পর্যন্ত
REFT01	বায়ু প্রতিরক্ষা ব্যবস্থার প্রবেশদ্বারে বায়ুমণ্ডলীয় বায়ুর তাপমাত্রা: ফ্লাইটে - মাইনাস 35 ºС থেকে 39 ºС।
REFP01	ফ্লাইটে স্থির বায়ুমণ্ডলীয় বায়ুর চাপ 700 থেকে 1013 hPa (526 থেকে 760 mm Hg পর্যন্ত)।
REFP02	ফ্লাইটে SVO এয়ার ইনটেকের প্রবেশপথে মোট বায়ুচাপ 754 থেকে 1200 hPa (566 থেকে 1050 mm Hg পর্যন্ত)।
RSGT01	শীতল বায়ু তাপমাত্রা: যখন পার্ক করা হয় 27 ºС এর বেশি নয়
RSGT02	শীতল বাতাসের তাপমাত্রা: পার্কিং লটে, প্রযুক্তিগত ইউনিটগুলির জন্য 29 ºС এর বেশি নয়
RSFT01	ফ্লাইটে শীতল বাতাসের তাপমাত্রা 25 ºС এর বেশি নয়
RSFT02	শীতল বায়ুর তাপমাত্রা: ফ্লাইটে, প্রযুক্তিগত ইউনিটগুলির জন্য 27 ºС এর বেশি নয়
RSGG01	শীতল বায়ু প্রবাহ: যখন পার্ক করা হয় তখন 708 কেজি/ঘন্টা কম হয় না
RSFG01	শীতল বায়ু প্রবাহ: ফ্লাইটে 660 kg/h এর কম নয়
RS0T01	যন্ত্রের বগিতে বাতাসের তাপমাত্রা 60 ºС এর বেশি নয়
RSH01	শীতল বাতাসে সূক্ষ্ম মুক্ত আর্দ্রতার পরিমাণ 2 গ্রাম/কেজি শুকনো বাতাসের বেশি নয়

প্রয়োজনীয়তা যাচাই সিস্টেম নকশা.

প্রতিটি ডিজাইনের প্রয়োজনীয়তার জন্য ডিজাইনের পরামিতি এবং প্রয়োজনীয়তার মধ্যে নির্দিষ্ট পরামিতিগুলির চিঠিপত্রের মূল্যায়নের জন্য একটি অ্যালগরিদম রয়েছে। সর্বোপরি, যেকোনো নিয়ন্ত্রণ ব্যবস্থায় সর্বদা প্রয়োজনীয়তা যাচাই করার জন্য ডিফল্টরূপে অ্যালগরিদম থাকে। এমনকি যে কোনো নিয়ন্ত্রক তাদের ধারণ করে। তাপমাত্রা সীমার বাইরে গেলে, এয়ার কন্ডিশনার চালু হয়। এইভাবে, যে কোনো প্রবিধানের প্রথম পর্যায়ে পরামিতিগুলি প্রয়োজনীয়তাগুলি পূরণ করে কিনা তা পরীক্ষা করা।

এবং যেহেতু যাচাইকরণ একটি অ্যালগরিদম, তাহলে আমরা একই সরঞ্জাম এবং সরঞ্জামগুলি ব্যবহার করতে পারি যা আমরা নিয়ন্ত্রণ প্রোগ্রাম তৈরি করতে ব্যবহার করি। উদাহরণ স্বরূপ, SimInTech এনভায়রনমেন্ট আপনাকে মডেলের বিভিন্ন অংশ সম্বলিত প্রজেক্ট প্যাকেজ তৈরি করতে দেয়, যা আলাদা প্রজেক্ট (অবজেক্ট মডেল, কন্ট্রোল সিস্টেম মডেল, এনভায়রনমেন্ট মডেল ইত্যাদি) আকারে কার্যকর করা হয়।

এই ক্ষেত্রে প্রয়োজনীয়তা যাচাইকরণ প্রকল্পটি একই অ্যালগরিদম প্রকল্পে পরিণত হয় এবং মডেল প্যাকেজের সাথে সংযুক্ত থাকে। এবং গতিশীল মডেলিং মোডে এটি প্রযুক্তিগত বৈশিষ্ট্যগুলির প্রয়োজনীয়তাগুলির সাথে সম্মতির জন্য একটি বিশ্লেষণ করে।

একটি সিস্টেম ডিজাইনের একটি সম্ভাব্য উদাহরণ চিত্র 1 এ দেখানো হয়েছে।

চিত্র 1. একটি যাচাইকরণ প্রকল্পের নকশার উদাহরণ।

ঠিক যেমন নিয়ন্ত্রণ অ্যালগরিদমগুলির জন্য, প্রয়োজনীয়তাগুলি শীটগুলির সেট হিসাবে তৈরি করা যেতে পারে। SimInTech, Simulink, AmeSim-এর মতো কাঠামোগত মডেলিং পরিবেশে অ্যালগরিদমের সাথে কাজ করার সুবিধার জন্য, সাবমডেল আকারে বহু-স্তরের কাঠামো তৈরি করার ক্ষমতা ব্যবহার করা হয়। এই সংস্থাটি বিভিন্ন প্রয়োজনীয়তাকে সেটে গোষ্ঠীভুক্ত করা সম্ভব করে যাতে বিভিন্ন প্রয়োজনীয়তার সাথে কাজ সহজতর করা যায়, যেমনটি নিয়ন্ত্রণ অ্যালগরিদমের জন্য করা হয় (চিত্র 2 দেখুন)।

চিত্র 2. প্রয়োজনীয়তা যাচাইকরণ মডেলের শ্রেণিবিন্যাস কাঠামো।

উদাহরণস্বরূপ, বিবেচনাধীন ক্ষেত্রে, দুটি গ্রুপকে আলাদা করা হয়েছে: পরিবেশের জন্য প্রয়োজনীয়তা এবং সরাসরি সিস্টেমের জন্য প্রয়োজনীয়তা। অতএব, একটি দ্বি-স্তরের ডেটা কাঠামো ব্যবহার করা হয়: দুটি গ্রুপ, যার প্রতিটি অ্যালগরিদমের একটি পাতা।

মডেলের সাথে ডেটা সংযোগ করতে, একটি সংকেত ডাটাবেস তৈরির জন্য একটি আদর্শ স্কিম ব্যবহার করা হয়, যা প্রকল্পের অংশগুলির মধ্যে বিনিময়ের জন্য ডেটা সঞ্চয় করে।

সফ্টওয়্যার তৈরি এবং পরীক্ষা করার সময়, নিয়ন্ত্রণ ব্যবস্থা দ্বারা ব্যবহৃত সেন্সরগুলির রিডিং (বাস্তব সিস্টেম সেন্সরগুলির অ্যানালগ) এই ডাটাবেসে স্থাপন করা হয়।
একটি পরীক্ষামূলক প্রকল্পের জন্য, গতিশীল মডেলে গণনা করা যেকোন পরামিতি একই ডাটাবেসে সংরক্ষণ করা যেতে পারে এবং এইভাবে প্রয়োজনীয়তাগুলি পূরণ হয়েছে কিনা তা পরীক্ষা করতে ব্যবহৃত হয়।

এই ক্ষেত্রে, গতিশীল মডেল নিজেই যে কোনও গাণিতিক মডেলিং সিস্টেমে বা এমনকি একটি এক্সিকিউটেবল প্রোগ্রামের আকারেও কার্যকর করা যেতে পারে। বাহ্যিক পরিবেশে মডেলিং ডেটা ইস্যু করার জন্য সফ্টওয়্যার ইন্টারফেসের উপস্থিতি একমাত্র প্রয়োজন।

চিত্র 3. যাচাইকরণ প্রকল্পটিকে জটিল মডেলের সাথে সংযুক্ত করা হচ্ছে।

একটি মৌলিক প্রয়োজনীয়তা যাচাইকরণ পত্রকের একটি উদাহরণ চিত্র 4-এ উপস্থাপন করা হয়েছে। বিকাশকারীর দৃষ্টিকোণ থেকে, এটি একটি প্রচলিত গণনা চিত্র যার উপর প্রয়োজনীয়তা যাচাইকরণ অ্যালগরিদম গ্রাফিকভাবে উপস্থাপন করা হয়েছে।

চিত্র 4. প্রয়োজনীয়তা চেক শীট.

চেক শীটের প্রধান অংশগুলি চিত্র 5 এ বর্ণনা করা হয়েছে। চেক অ্যালগরিদমটি নিয়ন্ত্রণ অ্যালগরিদমের নকশা চিত্রের অনুরূপভাবে গঠিত হয়। ডানদিকে ডাটাবেস থেকে সংকেত পড়ার জন্য একটি ব্লক রয়েছে। এই ব্লক সিমুলেশনের সময় সিগন্যাল ডাটাবেস অ্যাক্সেস করে।

প্রাপ্ত সংকেতগুলি প্রয়োজনীয়তা যাচাইয়ের শর্তগুলি গণনা করার জন্য বিশ্লেষণ করা হয়। এই ক্ষেত্রে, বিমানের অবস্থান নির্ধারণের জন্য উচ্চতা বিশ্লেষণ করা হয় (সেটি পার্ক করা হোক বা ফ্লাইটে)। এই উদ্দেশ্যে, আপনি মডেলের অন্যান্য সংকেত এবং গণনা করা পরামিতি ব্যবহার করতে পারেন।

যাচাইকরণের শর্তাবলী এবং পরামিতিগুলি পরীক্ষা করা হচ্ছে স্ট্যান্ডার্ড যাচাইকরণ ব্লকে স্থানান্তরিত করা হয়, যেখানে এই পরামিতিগুলি নির্দিষ্ট প্রয়োজনীয়তার সাথে সম্মতির জন্য বিশ্লেষণ করা হয়। ফলাফলগুলি সিগন্যাল ডাটাবেসে এমনভাবে রেকর্ড করা হয় যে সেগুলি স্বয়ংক্রিয়ভাবে একটি চেকলিস্ট তৈরি করতে ব্যবহার করা যেতে পারে।

চিত্র 5. প্রয়োজনীয়তা যাচাই গণনা শীট গঠন.

পরীক্ষিত পরামিতিগুলি অগত্যা ডাটাবেসে থাকা সংকেতগুলি ব্যবহার করে না, যা সিমুলেশন প্রক্রিয়া চলাকালীন গণনা করা পরামিতি দ্বারা নিয়ন্ত্রিত হয়। খসড়া প্রয়োজনীয়তার কাঠামোর মধ্যে অতিরিক্ত গণনা করা থেকে কিছুই আমাদের বাধা দেয় না, ঠিক যেমন আমরা যাচাইকরণের শর্তগুলি গণনা করি।

উদাহরণস্বরূপ, এই প্রয়োজনীয়তা:

লক্ষ্যে ফ্লাইটের সময় সংশোধন সিস্টেমের সক্রিয়করণের সংখ্যা 5 এর বেশি হওয়া উচিত নয় এবং সংশোধন সিস্টেমের মোট অপারেটিং সময় 30 সেকেন্ডের বেশি হওয়া উচিত নয়।

এই ক্ষেত্রে, শুরুর সংখ্যা এবং মোট অপারেটিং সময় মোকাবেলার জন্য একটি অ্যালগরিদম প্রয়োজনীয়তার নকশা চিত্রে যোগ করা হয়।

সাধারণ প্রয়োজনীয়তা যাচাইকরণ ব্লক।

প্রতিটি স্ট্যান্ডার্ড প্রয়োজনীয়তা চেক বক্স একটি নির্দিষ্ট ধরনের প্রয়োজনীয়তা পূরণের গণনা করার জন্য ডিজাইন করা হয়েছে। উদাহরণস্বরূপ, পরিবেশগত প্রয়োজনীয়তার মধ্যে পার্ক করা এবং ফ্লাইটে থাকাকালীন পরিবেষ্টিত অপারেটিং তাপমাত্রার একটি পরিসীমা অন্তর্ভুক্ত থাকে। এই ব্লকটিকে অবশ্যই একটি প্যারামিটার হিসাবে মডেলে বাতাসের তাপমাত্রা গ্রহণ করতে হবে এবং এই প্যারামিটারটি নির্দিষ্ট তাপমাত্রা পরিসীমা কভার করে কিনা তা নির্ধারণ করতে হবে৷</p>

ব্লকে দুটি ইনপুট পোর্ট রয়েছে, প্যারাম এবং কন্ডিশন।

প্রথমটি পরামিতি পরীক্ষা করা হচ্ছে। এই ক্ষেত্রে, "বাহ্যিক তাপমাত্রা"।

একটি বুলিয়ান ভেরিয়েবল দ্বিতীয় পোর্টে সরবরাহ করা হয় - চেক সম্পাদনের শর্ত।

যদি TRUE (1) দ্বিতীয় ইনপুটে প্রাপ্ত হয়, তাহলে ব্লকটি একটি প্রয়োজনীয় যাচাইকরণ গণনা করে।

যদি দ্বিতীয় ইনপুটটি FALSE (0) পায়, তাহলে পরীক্ষার শর্ত পূরণ করা হয় না। এটি প্রয়োজনীয় যাতে গণনার শর্তগুলি বিবেচনায় নেওয়া যায়। আমাদের ক্ষেত্রে, এই ইনপুটটি মডেলের অবস্থার উপর নির্ভর করে চেকটি সক্ষম বা নিষ্ক্রিয় করতে ব্যবহৃত হয়। যদি বিমানটি সিমুলেশনের সময় মাটিতে থাকে, তবে ফ্লাইট সম্পর্কিত প্রয়োজনীয়তাগুলি পরীক্ষা করা হয় না, এবং বিপরীতভাবে - যদি বিমানটি ফ্লাইটে থাকে, তবে স্ট্যান্ডে অপারেশন সম্পর্কিত প্রয়োজনীয়তাগুলি পরীক্ষা করা হয় না।

এই ইনপুটটি মডেল সেট আপ করার সময়ও ব্যবহার করা যেতে পারে, উদাহরণস্বরূপ গণনার প্রাথমিক পর্যায়ে। মডেলটিকে প্রয়োজনীয় অবস্থায় আনা হলে, চেক ব্লকগুলি অক্ষম করা হয়, কিন্তু সিস্টেমটি প্রয়োজনীয় অপারেটিং মোডে পৌঁছানোর সাথে সাথে চেক ব্লকগুলি চালু করা হয়।

এই ব্লকের পরামিতিগুলি হল:

• সীমানা শর্ত: উপরের (UpLimit) এবং নিম্ন (DownLimit) পরিসরের সীমা যা অবশ্যই চেক করা উচিত;
• প্রয়োজনীয় সিস্টেম এক্সপোজার সময় সীমানা রেঞ্জে (টাইম ইন্টারভাল) সেকেন্ডে;
• অনুরোধ আইডি ReqName;
• পরিসীমা অতিক্রম করার অনুমতিযোগ্যতা Out_range হল একটি বুলিয়ান ভেরিয়েবল যা নির্ধারণ করে যে চেক করা পরিসীমা অতিক্রম করা একটি মান প্রয়োজনের লঙ্ঘন কিনা।

কিছু ক্ষেত্রে, পরীক্ষার মান আউটপুট নির্দেশ করে যে সিস্টেমের কিছু মার্জিন রয়েছে এবং এটি তার অপারেটিং সীমার বাইরে কাজ করতে পারে। অন্যান্য ক্ষেত্রে, একটি আউটপুট মানে সিস্টেম সেটপয়েন্টগুলিকে সীমার মধ্যে রাখতে অক্ষম।

চিত্র 6. ডায়াগ্রামে একটি সাধারণ সম্পত্তি চেক ব্লক এবং এর পরামিতি।

এই ব্লকের গণনার ফলস্বরূপ, ফলাফল পরিবর্তনশীল আউটপুটে গঠিত হয়, যা নিম্নলিখিত মানগুলি নেয়:

• 0 – rNone, মান সংজ্ঞায়িত নয়;
• 1 – সম্পন্ন হয়েছে, প্রয়োজনীয়তা পূরণ হয়েছে;
• 2 - rফল্ট, প্রয়োজনীয়তা পূরণ করা হয় না.

ব্লক চিত্রটিতে রয়েছে:

• শনাক্তকারী পাঠ্য;
• পরিমাপ সীমা পরামিতি ডিজিটাল প্রদর্শন;
• পরামিতি অবস্থার রঙ শনাক্তকারী।

ব্লকের ভিতরে একটি জটিল লজিক্যাল ইনফারেন্স সার্কিট থাকতে পারে।

উদাহরণস্বরূপ, চিত্র 6 এ দেখানো ইউনিটের অপারেটিং তাপমাত্রা পরিসীমা পরীক্ষা করতে, অভ্যন্তরীণ সার্কিটটি চিত্র 7 এ দেখানো হয়েছে।

চিত্র 7. তাপমাত্রা পরিসীমা নির্ধারণ ইউনিটের অভ্যন্তরীণ চিত্র।

সার্কিট ব্লকের ভিতরে, ব্লক পরামিতিগুলিতে নির্দিষ্ট বৈশিষ্ট্যগুলি ব্যবহার করা হয়।
প্রয়োজনীয়তার সাথে সম্মতি বিশ্লেষণ করার পাশাপাশি, ব্লকের অভ্যন্তরীণ চিত্রে সিমুলেশন ফলাফল প্রদর্শনের জন্য প্রয়োজনীয় একটি গ্রাফ রয়েছে। এই গ্রাফটি গণনার সময় দেখার জন্য এবং গণনার পরে ফলাফল বিশ্লেষণের জন্য উভয়ই ব্যবহার করা যেতে পারে।

গণনার ফলাফলগুলি ব্লকের আউটপুটে প্রেরণ করা হয় এবং একই সাথে একটি সাধারণ রিপোর্ট ফাইলে রেকর্ড করা হয়, যা সমগ্র প্রকল্পের ফলাফলের উপর ভিত্তি করে তৈরি করা হয়। (চিত্র 8 দেখুন)

সিমুলেশন ফলাফলের উপর ভিত্তি করে তৈরি একটি প্রতিবেদনের একটি উদাহরণ হল একটি প্রদত্ত বিন্যাস অনুযায়ী তৈরি একটি HTML ফাইল। বিন্যাসটি একটি নির্দিষ্ট সংস্থা দ্বারা গৃহীত বিন্যাসে নির্বিচারে কনফিগার করা যেতে পারে।

সার্কিট ব্লকের ভিতরে, ব্লক পরামিতিগুলিতে নির্দিষ্ট বৈশিষ্ট্যগুলি ব্যবহার করা হয়।
প্রয়োজনীয়তার সাথে সম্মতি বিশ্লেষণ করার পাশাপাশি, ব্লকের অভ্যন্তরীণ চিত্রে সিমুলেশন ফলাফল প্রদর্শনের জন্য প্রয়োজনীয় একটি গ্রাফ রয়েছে। এই গ্রাফটি গণনার সময় দেখার জন্য এবং গণনার পরে ফলাফল বিশ্লেষণের জন্য উভয়ই ব্যবহার করা যেতে পারে।

গণনার ফলাফলগুলি ব্লকের আউটপুটে প্রেরণ করা হয় এবং একই সাথে একটি সাধারণ রিপোর্ট ফাইলে রেকর্ড করা হয়, যা সমগ্র প্রকল্পের ফলাফলের উপর ভিত্তি করে তৈরি করা হয়। (চিত্র 8 দেখুন)

সিমুলেশন ফলাফলের উপর ভিত্তি করে তৈরি একটি প্রতিবেদনের একটি উদাহরণ হল একটি প্রদত্ত বিন্যাস অনুযায়ী তৈরি একটি HTML ফাইল। বিন্যাসটি একটি নির্দিষ্ট সংস্থা দ্বারা গৃহীত বিন্যাসে নির্বিচারে কনফিগার করা যেতে পারে।

চিত্র 8. সিমুলেশন ফলাফলের উপর ভিত্তি করে একটি রিপোর্ট ফাইলের উদাহরণ।

এই উদাহরণে, রিপোর্ট ফর্মটি সরাসরি প্রকল্পের বৈশিষ্ট্যগুলিতে কনফিগার করা হয়েছে এবং টেবিলের বিন্যাসটি বিশ্বব্যাপী প্রকল্প সংকেত হিসাবে সেট করা হয়েছে। এই ক্ষেত্রে, SimInTech নিজেই রিপোর্ট সেট আপ করার সমস্যা সমাধান করে, এবং একটি ফাইলে ফলাফল লেখার জন্য ব্লক রিপোর্ট ফাইলে লিখতে এই লাইনগুলি ব্যবহার করে।

চিত্র 9. গ্লোবাল প্রজেক্ট সিগন্যালে রিপোর্ট ফরম্যাট সেট করা

প্রয়োজনীয়তার জন্য একটি সংকেত ডাটাবেস ব্যবহার করা।

সম্পত্তি সেটিংস সহ কাজ স্বয়ংক্রিয় করতে, প্রতিটি সাধারণ ব্লকের জন্য সিগন্যাল ডাটাবেসে একটি আদর্শ কাঠামো তৈরি করা হয়। (চিত্র 10 দেখুন)

চিত্র 10. একটি সংকেত ডাটাবেসে প্রয়োজনীয় চেক ব্লকের কাঠামোর উদাহরণ।

সিগন্যাল ডাটাবেস প্রদান করে:

• সমস্ত প্রয়োজনীয় সিস্টেম প্রয়োজনীয়তা পরামিতি সংরক্ষণ করা।
• নির্দিষ্ট পরামিতি এবং বর্তমান মডেলিং ফলাফল থেকে বিদ্যমান প্রকল্প প্রয়োজনীয়তা সুবিধাজনক দেখার.
• একটি স্ক্রিপ্টিং প্রোগ্রামিং ভাষা ব্যবহার করে একটি ব্লক বা ব্লকের একটি গ্রুপ সেট আপ করা। সংকেত ডাটাবেসের পরিবর্তন ডায়াগ্রামে ব্লক সম্পত্তি মান পরিবর্তনের দিকে পরিচালিত করে।
• পাঠ্য বিবরণ সংরক্ষণ করা, প্রয়োজনীয়তা ব্যবস্থাপনা সিস্টেমে প্রযুক্তিগত বৈশিষ্ট্যের আইটেম বা শনাক্তকারীর লিঙ্ক।

প্রয়োজনীয়তার জন্য সিগন্যাল ডাটাবেস স্ট্রাকচারগুলি তৃতীয়-পক্ষের প্রয়োজনীয়তা ব্যবস্থাপনা সিস্টেমের সাথে কাজ করার জন্য সহজেই কনফিগার করা যেতে পারে। প্রয়োজনীয়তা পরিচালন সিস্টেমের সাথে ইন্টারঅ্যাকশনের একটি সাধারণ ডায়াগ্রাম চিত্র 11-এ উপস্থাপন করা হয়েছে।

চিত্র 11. প্রয়োজনীয়তা ব্যবস্থাপনা সিস্টেমের সাথে মিথস্ক্রিয়া ডায়াগ্রাম।

SimInTech পরীক্ষা প্রকল্প এবং প্রয়োজনীয় নিয়ন্ত্রণ ব্যবস্থার মধ্যে মিথস্ক্রিয়ার ক্রম নিম্নরূপ:

1. রেফারেন্স শর্তাবলী প্রয়োজনীয়তা মধ্যে বিভক্ত করা হয়.
2. প্রযুক্তিগত বৈশিষ্ট্যগুলির প্রয়োজনীয়তাগুলি চিহ্নিত করা হয় যা প্রযুক্তিগত প্রক্রিয়াগুলির গাণিতিক মডেলিং দ্বারা যাচাই করা যেতে পারে।
3. নির্বাচিত প্রয়োজনীয়তার বৈশিষ্ট্যগুলি স্ট্যান্ডার্ড ব্লকের কাঠামোতে SimInTech সংকেত ডাটাবেসে স্থানান্তরিত হয় (উদাহরণস্বরূপ, সর্বাধিক এবং সর্বনিম্ন তাপমাত্রা)।
4. গণনা প্রক্রিয়া চলাকালীন, কাঠামো ডেটা ব্লক ডিজাইন ডায়াগ্রামে স্থানান্তরিত হয়, বিশ্লেষণ করা হয় এবং ফলাফলগুলি একটি সংকেত ডাটাবেসে সংরক্ষণ করা হয়।
5. গণনা সম্পূর্ণ হলে, বিশ্লেষণের ফলাফল প্রয়োজনীয়তা ব্যবস্থাপনা সিস্টেমে স্থানান্তরিত হয়।

ডিজাইন এবং/অথবা প্রয়োজনীয়তার পরিবর্তন ঘটলে এবং পরিবর্তনের প্রভাব পুনরায় পরীক্ষা করার প্রয়োজন হলে প্রয়োজনীয় পদক্ষেপ 3 থেকে 5 ডিজাইন প্রক্রিয়ার সময় পুনরাবৃত্তি করা যেতে পারে।

উপসংহার।

• সিস্টেমের তৈরি প্রোটোটাইপ প্রযুক্তিগত বৈশিষ্ট্যগুলির প্রয়োজনীয়তাগুলির সাথে সম্মতির জন্য বিদ্যমান মডেলগুলির বিশ্লেষণের সময় একটি উল্লেখযোগ্য হ্রাস প্রদান করে।
• প্রস্তাবিত পরীক্ষার প্রযুক্তিটি ইতিমধ্যে বিদ্যমান গতিশীল মডেলগুলি ব্যবহার করে এবং SimInTech পরিবেশে সম্পাদিত না হওয়া সহ যে কোনও গতিশীল মডেলের জন্যও ব্যবহার করা যেতে পারে।
• ব্যাচ ডেটা অর্গানাইজেশন ব্যবহার করে আপনি মডেল ডেভেলপমেন্টের সমান্তরালে প্রয়োজনীয়তা যাচাইকরণ প্যাকেজ তৈরি করতে পারবেন, অথবা মডেল ডেভেলপমেন্টের জন্য প্রযুক্তিগত বৈশিষ্ট্য হিসাবে এই প্যাকেজগুলি ব্যবহার করতে পারবেন।
• প্রযুক্তিটি উল্লেখযোগ্য খরচ ছাড়াই বিদ্যমান প্রয়োজনীয়তা ব্যবস্থাপনা সিস্টেমের সাথে একীভূত করা যেতে পারে।

যারা শেষ পর্যন্ত পড়বেন তাদের জন্য, প্রোটোটাইপ কিভাবে কাজ করে তা দেখানো একটি ভিডিওর লিঙ্ক।

উত্স: www.habr.com