Tema devam ediyor , matematiksel modelleme problemine diğer taraftan bakalım. Modelin hayatın sade gerçeğine karşılık geldiğine ikna olduktan sonra asıl soruyu cevaplayabiliriz: "Burada tam olarak ne var?" Teknik bir nesnenin modelini oluştururken genellikle bu nesnenin beklentilerimizi karşılayacağından emin olmak isteriz. Bu amaçla süreçlerin dinamik hesaplamaları yapılır ve sonuç gereksinimlerle karşılaştırılır. Bu bir dijital ikiz, sanal bir prototip vb. Tasarım aşamasında planladığımız şeyi elde ettiğimizden nasıl emin olacağımız sorununu çözen modaya uygun küçük adamlar.
Sistemimizin tam olarak tasarladığımız şey olduğundan, tasarımımızın uçup uçmayacağından nasıl hızlı bir şekilde emin olabiliriz? Peki uçarsa ne kadar yükseğe uçar? Ve eğer yüzüyorsa, ne kadar derin?
Bu makalede, teknik sistemlerin dinamik modellerini oluştururken teknik bir binanın gereksinimlerine uygunluğun doğrulanmasının otomasyonu tartışılmaktadır. Örnek olarak, bir uçak hava soğutma sisteminin teknik spesifikasyonundaki bir öğeye bakalım.
Belirli bir hesaplama modeline dayalı olarak sayısal olarak ifade edilebilen ve matematiksel olarak doğrulanabilen gereksinimleri dikkate alıyoruz. Bunun herhangi bir teknik sistem için genel gereksinimlerin yalnızca bir parçası olduğu açıktır, ancak nesnenin dinamik modellerini oluşturmak için zaman, sinir ve para harcadığımız şey bunları kontrol etmektir.
Teknik gereksinimleri bir belge biçiminde açıklarken, her biri gereksinimlerin yerine getirilmesinin otomatik olarak doğrulanmasının oluşturulması için farklı yaklaşımlar gerektiren birkaç farklı gereksinim türü ayırt edilebilir.
Örneğin, şu küçük ama gerçekçi gereksinimler dizisini göz önünde bulundurun:
- Su arıtma sisteminin girişindeki atmosferik hava sıcaklığı:
otoparkta - eksi 35'ten 35 ºС'ye,
uçuşta - eksi 35'ten 39 ºС'ye. - Uçuş sırasında atmosferik havanın statik basıncı 700 ila 1013 GPa (526 ila 760 mm Hg) arasındadır.
- Uçuş sırasında SVO hava girişinin girişindeki toplam hava basıncı 754 ila 1200 GPa arasındadır (566 ila 1050 mm Hg).
- Soğutma havası sıcaklığı:
otoparkta - en fazla 27 ºС, teknik bloklar için - en fazla 29 ºС,
uçuşta - en fazla 25 ºС, teknik bloklar için - en fazla 27 ºС. - Soğutma hava akışı:
park halindeyken - en az 708 kg/saat,
uçuşta - en az 660 kg/saat. - Alet bölmelerindeki hava sıcaklığı 60 ºС'den fazla değildir.
- Soğutma havasındaki ince serbest nem miktarı kuru havanın kg'ı başına 2 g'dan fazla değildir.
Bu sınırlı gereksinimler dizisi içinde bile sistemde farklı şekilde ele alınması gereken en az iki kategori vardır:
- sistemin çalışma koşullarına ilişkin gereksinimler (madde 1-3);
- sistem için parametrik gereksinimler (madde 3-7).
Sistem çalışma koşulları gereksinimleri
Modelleme sırasında geliştirilmekte olan sistem için dış koşullar, sınır koşulları olarak veya genel sistemin işleyişinin bir sonucu olarak belirtilebilir.
Dinamik simülasyonda, belirlenen çalışma koşullarının simülasyon süreci tarafından kapsandığından emin olmak gerekir.
Parametrik sistem gereksinimleri
Bu gereksinimler sistemin kendisi tarafından sağlanan parametrelerdir. Modelleme sürecinde bu parametreleri hesaplama sonuçları olarak elde edebilir ve her özel hesaplamada gereksinimlerin karşılandığından emin olabiliriz.
Gereksinimlerin tanımlanması ve kodlanması
Gereksinimlerle çalışmayı kolaylaştırmak için mevcut standartlar, her gereksinime bir tanımlayıcı atanmasını önerir. Tanımlayıcıları atarken, birleşik bir kodlama sisteminin kullanılması oldukça arzu edilir.
Bir gereksinim kodu, gereksinimin sipariş numarasını temsil eden basit bir sayı olabilir veya bir gereksinim türü kodunu, uygulandığı sistem veya ünitenin kodunu, bir parametre kodunu, bir konum kodunu ve herhangi başka bir şeyi içerebilir. mühendis hayal edebiliyor. (kodlamanın kullanımı için makaleye bakın)
Tablo 1 gereksinim kodlamasının basit bir örneğini sunmaktadır.
- gereksinimlerin kaynağının kodu R-gereksinimleri TK;
- gereksinim türü kodu E - gereksinimler - çevresel parametreler veya çalışma koşulları
S - sistem tarafından sağlanan gereksinimler; - uçak durum kodu 0 – herhangi biri, G – park edilmiş, F – uçuşta;
- fiziksel parametre türü kodu T – sıcaklık, P – basınç, G – akış hızı, nem H;
- gereksinimin seri numarası.
| ID Gereksinimler |
Açıklama | Parametre |
| REGT01 | Su soğutma sisteminin girişindeki ortam hava sıcaklığı: otoparkta - eksi 35ºС'den. 35 ºС'ye kadar. | |
| REFT01 | Hava savunma sisteminin girişindeki atmosferik hava sıcaklığı: uçuş sırasında - eksi 35 ºС'den 39 ºС'ye. | |
| REFP01 | Uçuş sırasında statik atmosferik hava basıncı 700 ila 1013 hPa (526 ila 760 mm Hg) arasındadır. | |
| REFP02 | Uçuş sırasında SVO hava girişinin girişindeki toplam hava basıncı 754 ila 1200 hPa arasındadır (566 ila 1050 mm Hg). | |
| RSGT01 | Soğutma havası sıcaklığı: park edildiğinde 27 ºС'den fazla değil | |
| RSGT02 | Soğutma havası sıcaklığı: otoparkta, teknik üniteler için 29 ºС'den fazla değil | |
| RSFT01 | Uçuş sırasında soğutma havası sıcaklığı 25 ºС'den fazla değil | |
| RSFT02 | Soğutma havası sıcaklığı: uçuş sırasında, teknik üniteler için 27 ºС'den fazla değil | |
| RSGG01 | Soğutma havası akışı: park halindeyken en az 708 kg/saat | |
| RSFG01 | Soğutma havası akışı: uçuş sırasında en az 660 kg/saat | |
| RS0T01 | Alet bölmelerindeki hava sıcaklığı 60 ºС'den fazla değil | |
| RSH01 | Soğutma havasındaki ince serbest nem miktarı kuru havanın kg'ı başına 2 g'dan fazla değildir |
Gereksinim doğrulama sistemi tasarımı.
Her tasarım gereksinimi için, tasarım parametrelerinin ve gereksinimde belirtilen parametrelerin uygunluğunu değerlendirmek için bir algoritma vardır. Genel olarak herhangi bir kontrol sistemi, gereksinimleri kontrol etmek için her zaman varsayılan olarak algoritmalar içerir. Ve hatta herhangi bir düzenleyici bile bunları içerir. Sıcaklık limitlerin dışına çıkarsa klima açılır. Bu nedenle herhangi bir düzenlemenin ilk aşaması, parametrelerin gereksinimleri karşılayıp karşılamadığının kontrol edilmesidir.
Doğrulama bir algoritma olduğundan, kontrol programları oluşturmak için kullandığımız araçların ve araçların aynısını kullanabiliriz. Örneğin, SimInTech ortamı, modelin çeşitli bölümlerini içeren, ayrı projeler (nesne modeli, kontrol sistemi modeli, ortam modeli vb.) şeklinde yürütülen proje paketleri oluşturmanıza olanak tanır.
Bu durumda gereksinim doğrulama projesi aynı algoritma projesi haline gelir ve model paketine bağlanır. Dinamik modelleme modunda ise teknik şartnamelerin gereklerine uygunluk açısından bir analiz gerçekleştirir.
Sistem tasarımının olası bir örneği Şekil 1'de gösterilmektedir.
Şekil 1. Bir doğrulama projesinin tasarım örneği.
Tıpkı kontrol algoritmalarında olduğu gibi gereksinimler de bir takım sayfalar halinde hazırlanabilir. SimInTech, Simulink, AmeSim gibi yapısal modelleme ortamlarında algoritmalarla çalışmanın kolaylığı için alt modeller şeklinde çok seviyeli yapılar oluşturabilme yeteneğinden yararlanılmaktadır. Bu organizasyon, kontrol algoritmalarında yapıldığı gibi, bir dizi gereksinimle çalışmayı basitleştirmek için çeşitli gereksinimleri kümeler halinde gruplandırmayı mümkün kılar (bkz. Şekil 2).
Şekil 2. Gereksinim doğrulama modelinin hiyerarşik yapısı.
Örneğin, ele alınan durumda iki grup ayırt edilir: çevreye yönelik gereksinimler ve doğrudan sisteme ilişkin gereksinimler. Bu nedenle iki seviyeli bir veri yapısı kullanılır: her biri algoritmanın yaprağı olan iki grup.
Verileri modele bağlamak için, projenin bölümleri arasında veri alışverişi için verileri saklayan bir sinyal veritabanı oluşturmak için standart bir şema kullanılır.
Yazılımı oluştururken ve test ederken, kontrol sistemi tarafından kullanılan sensörlerin okumaları (gerçek sistem sensörlerinin analogları) bu veritabanına yerleştirilir.
Bir test projesi için dinamik modelde hesaplanan herhangi bir parametre aynı veritabanında saklanabilir ve böylece gereksinimlerin karşılanıp karşılanmadığını kontrol etmek için kullanılabilir.
Bu durumda dinamik modelin kendisi herhangi bir matematiksel modelleme sisteminde veya hatta çalıştırılabilir bir program biçiminde çalıştırılabilir. Tek gereklilik, modelleme verilerini dış ortama yayınlamak için yazılım arayüzlerinin varlığıdır.
Şekil 3. Doğrulama projesinin karmaşık modele bağlanması.
Temel gereksinim doğrulama sayfasının bir örneği Şekil 4'te gösterilmektedir. Geliştiricinin bakış açısından bu, gereksinim doğrulama algoritmasının grafiksel olarak sunulduğu geleneksel bir hesaplama şemasıdır.
Şekil 4. Gereksinimler kontrol sayfası.
Kontrol sayfasının ana kısımları Şekil 5'te açıklanmıştır. Kontrol algoritması, kontrol algoritmalarının tasarım diyagramlarına benzer şekilde oluşturulmuştur. Sağ tarafta veritabanından sinyalleri okumak için bir blok var. Bu blok simülasyon sırasında sinyal veritabanına erişir.
Alınan sinyaller, gereksinim doğrulama koşullarını hesaplamak için analiz edilir. Bu durumda uçağın konumunu (park halinde mi yoksa uçuşta mı olduğunu) belirlemek için irtifa analizi yapılır. Bu amaçla modelin diğer sinyallerini ve hesaplanan parametrelerini kullanabilirsiniz.
Doğrulama koşulları ve kontrol edilen parametreler, bu parametrelerin belirtilen gereksinimlere uygunluk açısından analiz edildiği standart doğrulama bloklarına aktarılır. Sonuçlar, otomatik olarak bir kontrol listesi oluşturmak için kullanılabilecek şekilde sinyal veri tabanına kaydedilir.
Şekil 5. Gereksinim doğrulama hesaplama tablosunun yapısı.
Test edilecek parametreler mutlaka veri tabanında bulunan ve simülasyon süreci sırasında hesaplanan parametreler tarafından kontrol edilen sinyalleri kullanmaz. Doğrulama koşullarını hesapladığımız gibi, taslak gereklilikler çerçevesinde ek hesaplamalar yapmamızı da hiçbir şey engellemiyor.
Örneğin bu gereksinim:
Hedefe uçuş sırasında düzeltme sisteminin aktivasyon sayısı 5'i, düzeltme sisteminin toplam çalışma süresi ise 30 saniyeyi geçmemelidir.
Bu durumda, gereksinimlerin tasarım şemasına başlatma sayısını ve toplam çalışma süresini saymaya yönelik bir algoritma eklenir.
Tipik gereksinimler doğrulama bloğu.
Her standart gereksinim onay kutusu, belirli türdeki bir gereksinimin karşılanmasını hesaplamak için tasarlanmıştır. Örneğin, çevresel gereksinimler park halindeyken ve uçuş sırasında çeşitli ortam çalışma sıcaklıklarını içerir. Bu blok modeldeki hava sıcaklığını parametre olarak almalı ve bu parametrenin belirlenen sıcaklık aralığını kapsayıp kapsamadığını belirlemelidir./p>
Blokta param ve durum olmak üzere iki giriş portu bulunur.
İlki kontrol edilen parametreyle beslenir. Bu durumda “Dış sıcaklık”.
İkinci bağlantı noktasına, kontrolü gerçekleştirme koşulu olan bir Boolean değişkeni sağlanır.
İkinci girişte TRUE (1) alınırsa blok gereksinim doğrulama hesaplaması yapar.
İkinci giriş FALSE (0) alırsa test koşulları karşılanmaz. Hesaplama koşullarının dikkate alınabilmesi için bu gereklidir. Bizim durumumuzda bu giriş, modelin durumuna bağlı olarak kontrolü etkinleştirmek veya devre dışı bırakmak için kullanılır. Simülasyon sırasında uçak yerdeyse, uçuşla ilgili gereklilikler kontrol edilmez ve bunun tersi de geçerlidir; eğer uçak uçuştaysa, park yerinde operasyonla ilgili gereklilikler kontrol edilmez.
Bu giriş, örneğin hesaplamanın ilk aşamasında model kurulurken de kullanılabilir. Model gerekli duruma getirildiğinde kontrol blokları devre dışı bırakılır ancak sistem gerekli çalışma moduna ulaştığında kontrol blokları açılır.
Bu bloğun parametreleri şunlardır:
- sınır koşulları: kontrol edilmesi gereken üst (UpLimit) ve alt (DownLimit) aralık sınırları;
- saniye cinsinden sınır aralıklarında gerekli sistem maruz kalma süresi (TimeInterval);
- İstek Kimliği İstekAdı;
- aralığı aşmanın izin verilebilirliği Out_range, kontrol edilen aralığı aşan bir değerin gereksinimin ihlali olup olmadığını belirleyen bir Boolean değişkenidir.
Bazı durumlarda test değeri çıkışı, sistemin bir miktar marjının olduğunu ve çalışma aralığının dışında çalışıyor olabileceğini gösterir. Diğer durumlarda çıkış, sistemin ayar noktalarını aralık dahilinde tutamadığı anlamına gelir.
Şekil 6. Diyagramdaki tipik bir özellik kontrol bloğu ve parametreleri.
Bu bloğun hesaplanması sonucunda çıktıda aşağıdaki değerleri alan Result değişkeni oluşturulur:
- 0 – rYok, değer tanımlanmadı;
- 1 – rBitti, gereksinim karşılandı;
- 2 – rArıza, gereksinim karşılanmıyor.
Blok resmi şunları içerir:
- tanımlayıcı metin;
- ölçüm limiti parametrelerinin dijital ekranları;
- parametre durumunun renk tanımlayıcısı.
Bloğun içinde oldukça karmaşık bir mantıksal çıkarım devresi olabilir.
Örneğin Şekil 6'da gösterilen ünitenin çalışma sıcaklığı aralığını kontrol etmek için iç devre Şekil 7'de gösterilmiştir.
Şekil 7. Sıcaklık aralığı belirleme ünitesinin iç diyagramı.
Devre bloğu içerisinde blok parametrelerinde belirtilen özellikler kullanılır.
Gereksinimlere uygunluğu analiz etmenin yanı sıra bloğun dahili diyagramı, simülasyon sonuçlarını görüntülemek için gerekli bir grafiği içerir. Bu grafik hem hesaplama sırasında görüntülemek hem de hesaplama sonrasında sonuçları analiz etmek için kullanılabilir.
Hesaplama sonuçları bloğun çıkışına iletilir ve aynı anda tüm projenin sonuçlarına göre oluşturulan genel bir rapor dosyasına kaydedilir. (bkz. Şekil 8)
Simülasyon sonuçlarına göre oluşturulan rapora örnek olarak belirli bir formata göre oluşturulan bir html dosyası verilebilir. Format, belirli bir kuruluş tarafından kabul edilen formata göre keyfi olarak yapılandırılabilir.
Devre bloğu içerisinde blok parametrelerinde belirtilen özellikler kullanılır.
Gereksinimlere uygunluğu analiz etmenin yanı sıra bloğun dahili diyagramı, simülasyon sonuçlarını görüntülemek için gerekli bir grafiği içerir. Bu grafik hem hesaplama sırasında görüntülemek hem de hesaplama sonrasında sonuçları analiz etmek için kullanılabilir.
Hesaplama sonuçları bloğun çıkışına iletilir ve aynı anda tüm projenin sonuçlarına göre oluşturulan genel bir rapor dosyasına kaydedilir. (bkz. Şekil 8)
Simülasyon sonuçlarına göre oluşturulan rapora örnek olarak belirli bir formata göre oluşturulan bir html dosyası verilebilir. Format, belirli bir kuruluş tarafından kabul edilen formata göre keyfi olarak yapılandırılabilir.
Şekil 8. Simülasyon sonuçlarına dayalı bir rapor dosyası örneği.
Bu örnekte rapor formu doğrudan proje özelliklerinde yapılandırılmıştır ve tablodaki format global proje sinyalleri olarak ayarlanmıştır. Bu durumda SimInTech, raporu ayarlama sorununu kendisi çözer ve sonuçların bir dosyaya yazılması bloğu, rapor dosyasına yazmak için bu satırları kullanır.
Şekil 9. Global proje sinyallerinde rapor formatını ayarlama
Gereksinimler için bir sinyal veritabanının kullanılması.
Özellik ayarlarıyla çalışmayı otomatikleştirmek için, her tipik blok için sinyal veritabanında standart bir yapı oluşturulur. (bkz. Şekil 10)
Şekil 10. Bir sinyal veritabanındaki gereksinim kontrol bloğunun yapısına örnek.
Sinyal veritabanı şunları sağlar:
- Gerekli tüm sistem gereksinimleri parametrelerinin saklanması.
- Belirtilen parametrelerden ve mevcut modelleme sonuçlarından mevcut proje gereksinimlerinin rahatça görüntülenmesi.
- Bir komut dosyası programlama dili kullanarak bir blok veya bir blok grubu oluşturma. Sinyal veri tabanındaki değişiklikler, diyagramdaki blok özellik değerlerinde değişikliklere yol açar.
- Metin açıklamalarının, teknik spesifikasyon öğelerine veya tanımlayıcılara olan bağlantıların gereksinim yönetimi sisteminde saklanması.
Gereksinimlere yönelik sinyal veritabanı yapıları, üçüncü taraf gereksinim yönetimi sistemiyle çalışacak şekilde kolayca yapılandırılabilir.Gereksinim yönetimi sistemleriyle etkileşimin genel bir şeması Şekil 11'de sunulmaktadır.
Şekil 11. Gereksinim yönetimi sistemi ile etkileşim şeması.
SimInTech test projesi ile gereksinim kontrol sistemi arasındaki etkileşim sırası aşağıdaki gibidir:
- Referans şartları gereksinimlere ayrılmıştır.
- Teknik şartnamelerin gereksinimleri, teknik süreçlerin matematiksel modellenmesiyle doğrulanabilecek şekilde tanımlanır.
- Seçilen gereksinimlerin özellikleri standart bloklar yapısında (örneğin maksimum ve minimum sıcaklık) SimInTech sinyal veri tabanına aktarılır.
- Hesaplama işlemi sırasında yapı verileri blok tasarım diyagramlarına aktarılır, analiz yapılır ve sonuçlar bir sinyal veri tabanında saklanır.
- Hesaplama tamamlandıktan sonra analiz sonuçları gereksinim yönetimi sistemine aktarılır.
Tasarımda ve/veya gereksinimlerde değişiklikler meydana geldiğinde ve değişikliklerin etkisinin yeniden test edilmesi gerektiğinde, tasarım süreci sırasında 3'ten 5'e kadar olan gereksinim adımları tekrarlanabilir.
Sonuç.
- Sistemin oluşturulan prototipi, mevcut modellerin teknik şartnamelerin gerekliliklerine uygunluğu açısından analiz süresinde önemli bir azalma sağlar.
- Önerilen test teknolojisi halihazırda mevcut dinamik modelleri kullanır ve SimInTech ortamında gerçekleştirilmeyenler de dahil olmak üzere herhangi bir dinamik model için bile kullanılabilir.
- Toplu veri organizasyonunu kullanmak, model geliştirmeye paralel olarak gereksinim doğrulama paketleri oluşturmanıza ve hatta bu paketleri model geliştirme için teknik özellikler olarak kullanmanıza olanak tanır.
- Teknoloji, önemli maliyetler olmadan mevcut gereksinim yönetimi sistemlerine entegre edilebilir.
Sonuna kadar okuyanlar için;
Kaynak: habr.com