Tiếp tục chủ đề , chúng ta hãy nhìn vấn đề mô hình toán học từ phía bên kia. Sau khi tin chắc rằng mô hình này phù hợp với thực tế tự nhiên của cuộc sống, chúng ta có thể trả lời câu hỏi chính: “Chính xác thì chúng ta có gì ở đây?” Khi tạo mô hình của một đối tượng kỹ thuật, chúng ta thường muốn đảm bảo rằng đối tượng này sẽ đáp ứng được mong đợi của chúng ta. Với mục đích này, các tính toán động của các quy trình được thực hiện và kết quả được so sánh với yêu cầu. Đây là bản song sinh kỹ thuật số, nguyên mẫu ảo, v.v. những chàng trai thời trang, ở giai đoạn thiết kế, giải quyết vấn đề làm thế nào để đảm bảo rằng chúng tôi đạt được những gì mình dự định.
Làm thế nào chúng ta có thể nhanh chóng đảm bảo rằng hệ thống của chúng ta chính xác như những gì chúng ta thiết kế, thiết kế của chúng ta sẽ bay hay nổi? Và nếu nó bay thì cao bao nhiêu? Và nếu nó nổi thì sâu bao nhiêu?
Bài viết này thảo luận về việc tự động hóa việc xác minh sự tuân thủ các yêu cầu của tòa nhà kỹ thuật khi tạo ra các mô hình động của hệ thống kỹ thuật. Ví dụ: chúng ta hãy xem xét một thành phần của thông số kỹ thuật cho hệ thống làm mát không khí trên máy bay.
Chúng tôi xem xét những yêu cầu có thể được biểu thị bằng số và được xác minh bằng toán học dựa trên mô hình tính toán cụ thể. Rõ ràng rằng đây chỉ là một phần trong các yêu cầu chung đối với bất kỳ hệ thống kỹ thuật nào, nhưng chính việc kiểm tra chúng khiến chúng ta tốn thời gian, thần kinh và tiền bạc để tạo ra các mô hình động của đối tượng.
Khi mô tả các yêu cầu kỹ thuật dưới dạng tài liệu, có thể phân biệt một số loại yêu cầu khác nhau, mỗi loại yêu cầu các cách tiếp cận khác nhau để hình thành xác minh tự động việc thực hiện các yêu cầu.
Ví dụ: hãy xem xét bộ yêu cầu nhỏ nhưng thực tế này:
- Nhiệt độ không khí khí quyển ở lối vào hệ thống xử lý nước:
trong bãi đậu xe - từ âm 35 đến 35 ºС,
trong chuyến bay - từ âm 35 đến 39 ºС. - Áp suất tĩnh của không khí trong khí quyển khi bay là từ 700 đến 1013 GPa (từ 526 đến 760 mm Hg).
- Tổng áp suất không khí ở lối vào cửa hút gió SVO trong chuyến bay là từ 754 đến 1200 GPa (từ 566 đến 1050 mm Hg).
- Nhiệt độ không khí làm mát:
trong bãi đậu xe - không quá 27 С, đối với khu kỹ thuật - không quá 29 С,
trong chuyến bay - không quá 25 С, đối với khối kỹ thuật - không quá 27 С. - Lưu lượng không khí làm mát:
khi đỗ - ít nhất 708 kg/h,
trong chuyến bay - không ít hơn 660 kg/h. - Nhiệt độ không khí trong khoang dụng cụ không quá 60 ºС.
- Lượng hơi ẩm tự do mịn trong không khí làm mát không quá 2 g/kg không khí khô.
Ngay cả trong nhóm yêu cầu hạn chế này, có ít nhất hai loại cần được xử lý khác nhau trong hệ thống:
- yêu cầu về điều kiện vận hành của hệ thống (mục 1-3);
- yêu cầu tham số cho hệ thống (mục 3-7).
Yêu cầu về điều kiện vận hành hệ thống
Các điều kiện bên ngoài đối với hệ thống đang được phát triển trong quá trình mô hình hóa có thể được xác định là các điều kiện biên hoặc là kết quả của hoạt động của hệ thống chung.
Trong mô phỏng động, cần đảm bảo rằng các điều kiện vận hành đã chỉ định được đáp ứng trong quá trình mô phỏng.
Yêu cầu hệ thống tham số
Những yêu cầu này là các thông số do chính hệ thống cung cấp. Trong quá trình lập mô hình, chúng ta có thể lấy các tham số này làm kết quả tính toán và đảm bảo đáp ứng yêu cầu trong từng phép tính cụ thể.
Xác định và mã hóa yêu cầu
Để dễ dàng làm việc với các yêu cầu, các tiêu chuẩn hiện tại khuyên bạn nên gán mã định danh cho từng yêu cầu. Khi ấn định các mã định danh, nên sử dụng một hệ thống mã hóa thống nhất.
Mã yêu cầu có thể chỉ đơn giản là một số đại diện cho số thứ tự của yêu cầu hoặc nó có thể chứa mã cho loại yêu cầu, mã cho hệ thống hoặc đơn vị áp dụng nó, mã tham số, mã vị trí và bất cứ điều gì khác mà kỹ sư có thể tưởng tượng. (xem bài viết về cách sử dụng mã hóa)
Bảng 1 cung cấp một ví dụ đơn giản về mã hóa yêu cầu.
- mã nguồn yêu cầu R-requirements TK;
- mã loại yêu cầu E - yêu cầu - thông số môi trường hoặc điều kiện vận hành
S - yêu cầu do hệ thống cung cấp; - mã trạng thái máy bay 0 – bất kỳ, G – đỗ, F – đang bay;
- mã loại thông số vật lý T – nhiệt độ, P – áp suất, G – tốc độ dòng chảy, độ ẩm H;
- số thứ tự của yêu cầu.
| ID Yêu cầu |
Описание | Thông số |
| REGT01 | Nhiệt độ không khí xung quanh ở lối vào hệ thống làm mát bằng nước: trong bãi đậu xe - từ âm 35°С. lên đến 35 С. | |
| REFT01 | Nhiệt độ không khí trong khí quyển ở lối vào hệ thống phòng không: trong chuyến bay - từ âm 35 С đến 39 С. | |
| REFP01 | Áp suất không khí tĩnh trong chuyến bay là từ 700 đến 1013 hPa (từ 526 đến 760 mm Hg). | |
| REFP02 | Tổng áp suất không khí ở lối vào cửa hút gió SVO trong chuyến bay là từ 754 đến 1200 hPa (từ 566 đến 1050 mm Hg). | |
| RSGT01 | Nhiệt độ không khí làm mát: khi đỗ xe không quá 27 ºС | |
| RSGT02 | Nhiệt độ không khí làm mát: trong bãi đậu xe, đối với đơn vị kỹ thuật không quá 29 ºС | |
| RSFT01 | Nhiệt độ không khí làm mát trong chuyến bay không quá 25 С | |
| RSFT02 | Nhiệt độ không khí làm mát: trong chuyến bay, đối với bộ phận kỹ thuật không quá 27 С | |
| RSGG01 | Lưu lượng gió làm mát: khi đỗ xe không dưới 708 kg/h | |
| RSFG01 | Luồng khí làm mát: trong chuyến bay không dưới 660 kg/h | |
| RS0T01 | Nhiệt độ không khí trong khoang dụng cụ không quá 60 ºС | |
| RSH01 | Lượng hơi ẩm tự do mịn trong không khí làm mát không quá 2 g/kg không khí khô |
Thiết kế hệ thống xác minh yêu cầu.
Đối với mỗi yêu cầu thiết kế, có một thuật toán để đánh giá sự tương ứng của các tham số thiết kế và các tham số được chỉ định trong yêu cầu. Nhìn chung, bất kỳ hệ thống điều khiển nào cũng luôn chứa các thuật toán để kiểm tra yêu cầu theo mặc định. Và thậm chí bất kỳ cơ quan quản lý nào cũng chứa chúng. Nếu nhiệt độ vượt quá giới hạn, điều hòa sẽ bật. Vì vậy, giai đoạn đầu tiên của bất kỳ quy định nào là kiểm tra xem các thông số có đáp ứng yêu cầu hay không.
Và vì xác minh là một thuật toán nên chúng tôi có thể sử dụng các công cụ và công cụ tương tự mà chúng tôi sử dụng để tạo chương trình kiểm soát. Ví dụ: môi trường SimInTech cho phép bạn tạo các gói dự án chứa nhiều phần khác nhau của mô hình, được thực thi dưới dạng các dự án riêng biệt (mô hình đối tượng, mô hình hệ thống điều khiển, mô hình môi trường, v.v.).
Dự án xác minh yêu cầu trong trường hợp này trở thành dự án thuật toán tương tự và được kết nối với gói mô hình. Và ở chế độ mô hình động, nó thực hiện phân tích về việc tuân thủ các yêu cầu của thông số kỹ thuật.
Một ví dụ có thể có về thiết kế hệ thống được hiển thị trong Hình 1.
Hình 1. Ví dụ về thiết kế một dự án xác minh.
Cũng giống như các thuật toán điều khiển, các yêu cầu có thể được lập thành một tập hợp các trang tính. Để thuận tiện khi làm việc với các thuật toán trong môi trường mô hình hóa cấu trúc như SimInTech, Simulink, AmeSim, khả năng tạo cấu trúc đa cấp dưới dạng mô hình con được sử dụng. Tổ chức này có thể nhóm các yêu cầu khác nhau thành các bộ để đơn giản hóa công việc với một loạt yêu cầu, như được thực hiện đối với các thuật toán điều khiển (xem Hình 2).
Hình 2. Cấu trúc phân cấp của mô hình xác minh yêu cầu.
Ví dụ, trong trường hợp đang xem xét, hai nhóm được phân biệt: các yêu cầu đối với môi trường và các yêu cầu trực tiếp đối với hệ thống. Do đó, cấu trúc dữ liệu hai cấp được sử dụng: hai nhóm, mỗi nhóm là một lá của thuật toán.
Để kết nối dữ liệu với mô hình, một sơ đồ tiêu chuẩn để tạo cơ sở dữ liệu tín hiệu được sử dụng để lưu trữ dữ liệu để trao đổi giữa các phần của dự án.
Khi tạo và kiểm tra phần mềm, số đọc của cảm biến (tương tự của cảm biến hệ thống thực) được hệ thống điều khiển sử dụng sẽ được đặt trong cơ sở dữ liệu này.
Đối với một dự án thử nghiệm, mọi tham số được tính toán trong mô hình động đều có thể được lưu trữ trong cùng một cơ sở dữ liệu và do đó được sử dụng để kiểm tra xem các yêu cầu có được đáp ứng hay không.
Trong trường hợp này, bản thân mô hình động có thể được thực thi trong bất kỳ hệ thống mô hình toán học nào hoặc thậm chí ở dạng chương trình thực thi. Yêu cầu duy nhất là sự hiện diện của giao diện phần mềm để phát dữ liệu mô hình hóa ra môi trường bên ngoài.
Hình 3. Kết nối dự án xác minh với mô hình phức tạp.
Một ví dụ về bảng xác minh các yêu cầu cơ bản được trình bày trong Hình 4. Theo quan điểm của nhà phát triển, đây là một sơ đồ tính toán thông thường trên đó thuật toán xác minh yêu cầu được trình bày bằng đồ họa.
Hình 4. Bảng kiểm tra yêu cầu.
Các phần chính của phiếu kiểm tra được mô tả trên Hình 5. Thuật toán kiểm tra được hình thành tương tự như sơ đồ thiết kế của thuật toán điều khiển. Ở bên phải có khối đọc tín hiệu từ cơ sở dữ liệu. Khối này truy cập cơ sở dữ liệu tín hiệu trong quá trình mô phỏng.
Các tín hiệu nhận được sẽ được phân tích để tính toán các điều kiện xác minh yêu cầu. Trong trường hợp này, phân tích độ cao được thực hiện để xác định vị trí của máy bay (cho dù nó đang đỗ hay đang bay). Với mục đích này, bạn có thể sử dụng các tín hiệu và tham số tính toán khác của mô hình.
Các điều kiện xác minh và thông số đang được kiểm tra sẽ được chuyển đến các khối xác minh tiêu chuẩn, trong đó các thông số này được phân tích để đảm bảo tuân thủ các yêu cầu đã chỉ định. Các kết quả được ghi lại trong cơ sở dữ liệu tín hiệu theo cách mà chúng có thể được sử dụng để tự động tạo danh sách kiểm tra.
Hình 5. Cấu trúc của bảng tính xác minh yêu cầu.
Các tham số được kiểm tra không nhất thiết phải sử dụng các tín hiệu có trong cơ sở dữ liệu mà được điều khiển bởi các tham số được tính toán trong quá trình mô phỏng. Không có gì ngăn cản chúng tôi thực hiện các tính toán bổ sung trong khuôn khổ các yêu cầu dự thảo, giống như chúng tôi tính toán các điều kiện xác minh.
Ví dụ: yêu cầu này:
Số lần kích hoạt hệ thống hiệu chỉnh trong chuyến bay tới mục tiêu không được vượt quá 5 và tổng thời gian hoạt động của hệ thống hiệu chỉnh không quá 30 giây.
Trong trường hợp này, một thuật toán để đếm số lần khởi động và tổng thời gian vận hành sẽ được thêm vào sơ đồ thiết kế của các yêu cầu.
Khối xác minh yêu cầu điển hình.
Mỗi hộp kiểm yêu cầu tiêu chuẩn được thiết kế để tính toán việc đáp ứng yêu cầu của một loại nhất định. Ví dụ, các yêu cầu về môi trường bao gồm phạm vi nhiệt độ hoạt động xung quanh khi đỗ và trong chuyến bay. Khối này phải nhận nhiệt độ không khí trong mô hình làm tham số và xác định xem tham số này có bao gồm phạm vi nhiệt độ đã chỉ định hay không./p>
Khối này chứa hai cổng đầu vào, param và condition.
Cái đầu tiên được cung cấp thông số đang được kiểm tra. Trong trường hợp này là “Nhiệt độ bên ngoài”.
Một biến Boolean được cung cấp cho cổng thứ hai - điều kiện để thực hiện kiểm tra.
Nếu nhận được TRUE (1) ở đầu vào thứ hai thì khối sẽ thực hiện tính toán xác minh yêu cầu.
Nếu đầu vào thứ hai nhận được FALSE (0), thì điều kiện kiểm tra không được đáp ứng. Điều này là cần thiết để có thể tính đến các điều kiện tính toán. Trong trường hợp của chúng tôi, đầu vào này được sử dụng để bật hoặc tắt kiểm tra tùy thuộc vào trạng thái của mô hình. Nếu máy bay ở trên mặt đất trong quá trình mô phỏng thì các yêu cầu liên quan đến chuyến bay sẽ không được kiểm tra và ngược lại - nếu máy bay đang bay thì các yêu cầu liên quan đến hoạt động tại vị trí đỗ sẽ không được kiểm tra.
Đầu vào này cũng có thể được sử dụng khi thiết lập mô hình, ví dụ như ở giai đoạn tính toán ban đầu. Khi mô hình được đưa về trạng thái yêu cầu, các đơn vị xác minh sẽ bị vô hiệu hóa, nhưng ngay khi hệ thống đạt đến chế độ vận hành được yêu cầu, các đơn vị xác minh sẽ được bật.
Các tham số của khối này là:
- điều kiện biên: giới hạn phạm vi trên (UpLimit) và dưới (DownLimit) phải được kiểm tra;
- thời gian phơi sáng hệ thống cần thiết ở phạm vi ranh giới (TimeInterval) tính bằng giây;
- ID yêu cầu Tên yêu cầu;
- khả năng cho phép vượt quá phạm vi Out_range là biến Boolean xác định xem giá trị vượt quá phạm vi đã kiểm tra có vi phạm yêu cầu hay không.
Trong một số trường hợp, giá trị đầu ra của thử nghiệm chỉ ra rằng hệ thống có một số giới hạn và có thể đang hoạt động ngoài phạm vi hoạt động của nó. Trong các trường hợp khác, đầu ra có nghĩa là hệ thống không thể giữ các điểm đặt trong phạm vi.
Hình 6. Khối kiểm tra thuộc tính điển hình trong sơ đồ và các tham số của nó.
Kết quả của việc tính toán khối này là biến Kết quả được hình thành ở đầu ra, nhận các giá trị sau:
- 0 – rNone, giá trị không được xác định;
- 1 – rXong, đạt yêu cầu;
- 2 – rLỗi, không đạt yêu cầu.
Hình ảnh khối chứa:
- văn bản nhận dạng;
- hiển thị kỹ thuật số các thông số giới hạn đo;
- mã định danh màu của trạng thái tham số.
Bên trong khối có thể có một mạch suy luận logic khá phức tạp.
Ví dụ, để kiểm tra phạm vi nhiệt độ hoạt động của thiết bị được hiển thị trong Hình 6, mạch bên trong được hiển thị trong Hình 7.
Hình 7. Sơ đồ bên trong của thiết bị xác định phạm vi nhiệt độ.
Bên trong khối mạch, các thuộc tính được chỉ định trong tham số khối được sử dụng.
Ngoài việc phân tích việc tuân thủ các yêu cầu, sơ đồ bên trong của khối còn chứa một biểu đồ cần thiết để hiển thị kết quả mô phỏng. Biểu đồ này có thể được sử dụng để xem trong quá trình tính toán và phân tích kết quả sau khi tính toán.
Kết quả tính toán được truyền đến đầu ra của khối và được ghi đồng thời vào file báo cáo chung, được tạo dựa trên kết quả của toàn bộ dự án. (xem Hình 8)
Ví dụ về báo cáo được tạo dựa trên kết quả mô phỏng là tệp html được tạo theo định dạng nhất định. Định dạng có thể được cấu hình tùy ý theo định dạng được một tổ chức cụ thể chấp nhận.
Bên trong khối mạch, các thuộc tính được chỉ định trong tham số khối được sử dụng.
Ngoài việc phân tích việc tuân thủ các yêu cầu, sơ đồ bên trong của khối còn chứa một biểu đồ cần thiết để hiển thị kết quả mô phỏng. Biểu đồ này có thể được sử dụng để xem trong quá trình tính toán và phân tích kết quả sau khi tính toán.
Kết quả tính toán được truyền đến đầu ra của khối và được ghi đồng thời vào file báo cáo chung, được tạo dựa trên kết quả của toàn bộ dự án. (xem Hình 8)
Ví dụ về báo cáo được tạo dựa trên kết quả mô phỏng là tệp html được tạo theo định dạng nhất định. Định dạng có thể được cấu hình tùy ý theo định dạng được một tổ chức cụ thể chấp nhận.
Hình 8. Ví dụ về tệp báo cáo dựa trên kết quả mô phỏng.
Trong ví dụ này, biểu mẫu báo cáo được đặt cấu hình trực tiếp trong thuộc tính dự án và định dạng trong bảng được đặt làm tín hiệu dự án chung. Trong trường hợp này, SimInTech tự giải quyết vấn đề thiết lập báo cáo và khối ghi kết quả vào tệp sử dụng các dòng này để ghi vào tệp báo cáo.
Hình 9. Thiết lập định dạng báo cáo trong tín hiệu dự án toàn cầu
Sử dụng cơ sở dữ liệu tín hiệu cho các yêu cầu.
Để tự động hóa công việc với cài đặt thuộc tính, cấu trúc tiêu chuẩn được tạo trong cơ sở dữ liệu tín hiệu cho từng khối điển hình. (xem Hình 10)
Hình 10. Ví dụ về cấu trúc của khối kiểm tra yêu cầu trong cơ sở dữ liệu tín hiệu.
Cơ sở dữ liệu tín hiệu cung cấp:
- Lưu trữ tất cả các tham số yêu cầu hệ thống cần thiết.
- Xem thuận tiện các yêu cầu hiện tại của dự án từ các tham số được chỉ định và kết quả mô hình hóa hiện tại.
- Thiết lập một khối hoặc một nhóm khối bằng ngôn ngữ lập trình tập lệnh. Những thay đổi trong cơ sở dữ liệu tín hiệu dẫn đến thay đổi giá trị thuộc tính khối trong sơ đồ.
- Lưu trữ các mô tả văn bản, liên kết đến các mục thông số kỹ thuật hoặc mã định danh trong hệ thống quản lý yêu cầu.
Cấu trúc cơ sở dữ liệu tín hiệu cho các yêu cầu có thể được cấu hình dễ dàng để hoạt động với hệ thống quản lý yêu cầu của bên thứ 11. Sơ đồ chung về tương tác với các hệ thống quản lý yêu cầu được trình bày trong Hình XNUMX.
Hình 11. Sơ đồ tương tác với hệ thống quản lý yêu cầu.
Trình tự tương tác giữa dự án thử nghiệm SimInTech và hệ thống kiểm soát yêu cầu như sau:
- Các điều khoản tham chiếu được chia thành các yêu cầu.
- Các yêu cầu của thông số kỹ thuật được xác định và có thể được xác minh bằng mô hình toán học của các quy trình kỹ thuật.
- Các thuộc tính của các yêu cầu đã chọn sẽ được chuyển đến cơ sở dữ liệu tín hiệu SimInTech theo cấu trúc các khối tiêu chuẩn (ví dụ: nhiệt độ tối đa và tối thiểu).
- Trong quá trình tính toán, dữ liệu cấu trúc được chuyển sang sơ đồ thiết kế khối, thực hiện phân tích và kết quả được lưu trữ trong cơ sở dữ liệu tín hiệu.
- Sau khi tính toán hoàn tất, kết quả phân tích sẽ được chuyển đến hệ thống quản lý yêu cầu.
Các bước yêu cầu từ 3 đến 5 có thể được lặp lại trong quá trình thiết kế khi có thay đổi về thiết kế và/hoặc yêu cầu và tác động của những thay đổi đó cần phải được kiểm tra lại.
Kết luận.
- Nguyên mẫu được tạo ra của hệ thống giúp giảm đáng kể thời gian phân tích các mô hình hiện có để tuân thủ các yêu cầu của thông số kỹ thuật.
- Công nghệ thử nghiệm được đề xuất sử dụng các mô hình động hiện có và thậm chí có thể được sử dụng cho bất kỳ mô hình động nào, kể cả những mô hình không được thực hiện trong môi trường SimInTech.
- Việc sử dụng tổ chức dữ liệu hàng loạt cho phép bạn tạo các gói xác minh yêu cầu song song với việc phát triển mô hình hoặc thậm chí sử dụng các gói này làm thông số kỹ thuật để phát triển mô hình.
- Công nghệ này có thể được tích hợp với các hệ thống quản lý yêu cầu hiện có mà không tốn nhiều chi phí.
Dành cho những ai đọc đến cuối,
Nguồn: www.habr.com