Khóa luận tốt nghiệp Kỹ thuật máy tính: Nghiên cứu và mô phỏng Autosar

AUTOSAR cho phép các cơ sở hạ tầng của xe 6 tô ngày nay dần được hoàn thiện về mặt kết nối bởi một kiếntrúc phần mềm đi kèm với hệ điều hành được thiết kế để tính toán hiệu suất cao và t

XÂY DỰNG HE THONG MÔ PHONG AUTOSAR

Tổng quan về phần mềm . - 2 2 2+ +E+EE+EE+EE£EE2E£E£EEerEerkrrxrreee 29 3.2 File ARXML -.'""-"-

Các tiêu chuẩn sử dụng: AUTOSAR, chuẩn giao tiếp CAN, Platform SDK.

Mô tả phần mềm: Phần mềm mô phỏng thiết kế của động cơ đánh lái ô tô, được xây dựng ở bước Software Design và Integration Testing trong mô hình V-Model với mục đích kiểm tra sự liên kết của các SW-C dựa trên danh sách các yêu cầu cụ thé từ khách hàng Tat cả quá trình này có tên gọi là Component Integration

Testing (CIT) và được thực hiện sau khi bước Unit Test đã hoàn thành theo mô hình V-Model.

Ngôn ngữ chính sử dụng: C, Python.

IDE sử dụng: Visual Studio.

Hình 3-1: Mô hình hoạt động của phan mềm Softcar

Hình 3-1 thé hiện cấu trúc của phần mềm Softcar khi hoạt động, mô hình được chia thành hai phần chính là: khối điều khiển và khối chức năng ngoài Nguyên tắc hoạt động và chức năng chính của từng phân được mô tả như sau:

Khối điều khiến thực hiện việc nhận thông tin từ các bước mô phỏng bằng tay hoặc mô phỏng bằng Test-Case trong bước kiêm thử, sau đó thê hiện lên màn hình kết quả tương ứng với các mô phỏng đó bằng việc thay đôi các giá tri Interface.

Khối điều khiển gồm các thành phần nhỏ hơn bên trong với các chức năng chính như sau: e Python: phần mềm Softcar trong quá trình xây dựng và thực thi luôn cần sử dụng một số các thư viện Python được cấu hình riêng cho hệ thông. e Access Board: các cửa số trên phần mềm được tích hợp một số mô-đun chức năng hệ thống và mô-đun chức năng cho người dùng Đối với người Tester thực hiện việc kiểm tra phần mềm, Access Board sẽ là phần được quan sát và làm việc nhiều nhất trong phần mềm.

Với các mô-đun chức năng của hệ thống, Access Board sẽ tự động cập nhật các giá trị của các Interface đang xuất hiện theo hệ thống thời gian thực (thông thường mỗi lần nhảy số khoảng trên dưới 1 giây), tuy nhiên các giá trị thực sự thay đổi trong thời gian rất ngắn, gồm các khoảng 2, 4, 10 và 20 Cycle 1 lần tùy vào Interface đó đang nằm 6 Task bao nhiêu mili giây đang được thực thi (1 Cycle = 0.5ms) Ngoài ra, Access Board còn được hỗ trợ hiển thị giá tri Interface với nhiều kiểu giá trị khác nhau như giá trị vật lý, giá trị thập phân, giá trị nhị phân và giá trị thập lục phân.

Với các mô-đun chức năng cho người dùng, Access Board cho phép người dùng thực hiện một số tác vụ như truy xuất vào danh sách các Interface, lọc theo tên và chọn lựa Interface sẽ xuất hiện trên Access Board, thay đôi giá trị các Interface, lựa chọn kiều giá tri hién thi. e Object: các đối tượng mô-đun được sử dung trong phan mềm. e Additional Model: là các thành phần bên ngoài phạm vi phần mềm Softcar được cấu hình để điều khiển một số các mô-đun của Softcar, trong phạm vi

Khóa luận nay thi Additional Model có sử dụng là Eclipse cùng các Test-

Case với các thư viện Python trong quá trình kiểm thử, không có thành phần này thì Softcar vẫn hoạt động bình thường. e Softcar Excutable: thành phan chinh diéu khién hoat động cua Softcar, nhận thông tin dữ liệu từ Access Board, truy xuất vào Source Code và thực thi các phép nội suy dé lấy ra các giá trị Output, sau đó gan giá trị trả về vào các

Khối chức năng ngoài là Microsoft Visual Studio, có nhiệm vụ dừng các tác vụ đang thực thi ở thời điểm mong muốn và thực hiện việc thay đổi giá trị của Interface ngay thời điểm đó với mục đích kiểm tra tính đúng đắn của phần mềm đối với những lỗi không phát hiện được bằng Test-Case hoặc mô phỏng thủ công. Trong quá trình Debug, Khối điều khiển sẽ nhận Debug information từ khối này và thực thi với các giá trị tương ứng.

File ARXML là file cấu hình được lưu ở định dạng AUTOSAR XML (AUTOSAR Extensible Markup Language, gọi tắt là ARXML), loại file này đặc trưng cho kiến trúc AUTOSAR Các file ARXML chứa thông tin cấu hình và thông số kỹ thuật của ECU được sử dụng dé điều khiển các SW-C Quá trình xây dựng phần mềm cần sử dụng một hoặc nhiều tap tin ARXML dé xuất ra các Bus cần sử dụng. Các tập tin này chứa tất cả các thông số về tín hiệu được định nghĩa trong hệ thống tay lái của xe, trong đó có một sô phân quan trọng cân lưu ý như sau: e Protocol Data Unit (PDU): là một cụm tín hiệu chứa các tín hiệu con, thông thường một PDU sẽ chứa các tín hiệu con liên quan đến giá trị chính được vận hành trên xe và các cờ để kiểm tra lỗi (Signal not available,

Cyclic Redundancy Check (CRC), Message Counter Check, ) e Tín hiệu con: là một thành phan của PDU được dùng dé đặt tên cho Bus- tham số quan trọng nhất trong phần mềm.

Hệ số chuyển đổi: trong phần mềm sẽ có hai loại giá trị là giá trị vật lý được thể hiện khi vận hành xe và giá trị được thể hiện trên phần mềm, hệ sỐ chuyển đổi của từng tín hiệu sẽ được định nghĩa rõ trong tập tin.

Don vi: đơn vi vat lý của các tín hiệu (km/h, N/m, )

Các thành phan cần thiéte ccccecccccccsessesscessessessessessessesseestessessessesseesseeseesees 32 3.4 Phurong phap occ cee e

Dé xây dựng được hệ thống cho phần mềm Softcar, ta cần có đầy đủ các thành phân cân thiệt, chỉ cân thiêu một trong sô các phân này, việc biên dịch sẽ không thành công Những thành phần cần thiết bao gồm:

File ARXML theo đúng tiêu chuẩn.

Source code sử dụng làm Platform cho dự án: tập hợp các file từ SDK được dùng làm Platform cho dự án Vì một trong những đặc trưng của

AUTOSAR là tính tái sử dụng, nên mỗi dự án sẽ dùng một phần nhất định từ Platform, còn lại là những đặc trưng riêng của dự án.

Source code riêng cho dự án: tập hợp các file được thiết kế riêng cho dự án, trong đó có tất cả những thông số liên quan đến dự án bao gồm cả thông số về phần cứng và phần mềm dùng để xây dựng các lớp, các file chứa hệ số chuyền déi,

Bộ tool riêng dùng để đọc file ARXML và tham gia vào quá trình xây dựng hệ thống Nếu phần mềm được xây dựng thành công, cùng với chương trình thực thi, ta sẽ thu được một tập tin chứa toàn bộ các Bus sau khi đã được phân tích.

Sau khi đã có đầy đủ Source và các tool cần thiết, em hiện thực quá trình xây dựng như trong sơ đồ Hình 3-2 sau:

Hình 3-2: Sơ đồ giải thuật

Giao diện chính của Visual Studio sẽ chứa một Project chính là được đặt tên theo tên của dự án và model cua Platform Kèm theo đó sẽ là các Project phụ được định nghĩa bởi các đường dan đên các tập tin *.c cân cho việc biên dich phân mêm.

Mỗi dự án sẽ có nhiều Variant khác nhau tương ứng với các mẫu xe khác nhau, để việc biên dịch được chính xác, ta phải cau hình đúng tuyệt đối các đường dẫn trong Project phụ để dẫn đến đúng các tập tin cần thiết, tránh xảy ra lỗi trong quá trình biên dịch.

Một số lỗi thường gặp trong quá trình biên dịch và các giải quyết: e File ARXML gặp lỗi: tiến hành phân tích các lỗi gặp phải, nếu lỗi do phần công cụ đọc file, ta sẽ tiến hành chỉnh sửa sao cho phù hợp; nếu lỗi do file bị thiếu dữ liệu, ta sẽ liên hệ với bên khách hàng và yêu cầu cung cấp lại file mới theo đúng tiêu chuẩn. e Lỗi đường dân: tiên hành chỉnh sửa lại các đường dan chính xác.

33 e Lỗi liên quan trực tiếp đến phần cứng như Compiler không đọc được các hàm liên quan đến phần cứng như asm (Assembly) hoặc các hàm liên quan đến thanh ghi, tiến hành bỏ qua các hàm này và tiếp tục quá trình biên dịch vì hệ thống thực thi dựa trên các Bus, không bị phụ thuộc vào các giá tri phần cứng. e Lỗi về Source Code: vì trong mô hình V-Model, phần mềm được xây dựng với mục đích kiểm tra Integration Testing, trong khi hệ thống Source Code lại được thiết kế cho cả việc kiểm thử trên Unit Test và System Test Do đó, khó có thể tránh khỏi những lỗi mâu thuẫn giữa các quá trình với nhau.

Trong trường hợp này, sẽ có các cuộc họp nhỏ để cùng tìm ra hướng giải quyết giữa các nhóm với nhau, sau đó sẽ đưa ra phương án giải quyết thích hợp.

Sau khi quá trình biên dịch kết thúc và thành công, ta sẽ thu được một thư mục chứa các thông tin sau: e Tập hợp các tập tin chứa tat cả các hệ số chuyên đồi biến số từ giá trị vật lý sang giá trị phần mềm và chứa các quy định về giá trị biến, các khoảng giá trị valid, invalid va SNA (Signal Not Available). e Các thông số trong quá trình biên dịch e Cac thư mục thực thi phần mềm, bao gồm cấu hình hệ thống và các giá trị ban đầu được nạp vào phần mềm. e File Output của quá trình đọc file ARXML, file này chứa toàn bộ các thông tin về PDU: tên, độ dài, các tín hiệu con là các Bus đã được tông hợp thành một biến số và có thé truy xuất dé sử dụng trực tiếp trên phần mềm thực thi.

3.6 Giao diện và phương thức hoạt động

$ Softcar BMW_CLAR_WE_SCU3B3_SC (c:\eps_deplo hp2hc_CIT_Environment_CLARWE\SiL\08\BMW_CLAR_WE_SCU3B3_SC\bin\scsil.ini] — a

File Display Settings Window Application AZG/EDIC CAN Fleray Analog Signals About

Wiel elt JO pjwlylel tjigmm — 1_4/-|

- Run-Control- lâppll_RackPosition_xds16 Name Value

0.000 mm Continue |[_ so | Newtone | Net |[— 53]| SEN GhhiiIDE E1) out of range Í— Breakpoint [variables aren't physically) sAppll_EcuState_xdud 3 Idec sccEventMemory xdu32 00000000000000000000000000000000 [bin]

= B#ằeem cAppll_InternTempFilt_xdu8 80.000 degC

G33, JjIEcza-|j_ bữa Ho Reset ||| iappll “AllowedBattCurr_xdu16 4095.938 A

Blackboard Contal Variable Count iAppll_BatteryCurrent_xds16 2047.938 A Aeces | Display | Info [— sr iAppll_MaxAllowedStaticCurrent_xdu16 doesn't exist iAppll_MaxBattCurr_xdu16 200.000 A

Intemal Processes Dontol xAppli_ GearSign_xds8 1.000 -

€ Script @ Generator C Stimuli C Equatio © Trace | xAppll_TotalMotTorLim_xdu16 1.000 -

Run Stop Config Status [Sleep

Value gdb 0 [deg fScIntl I ize_gúb 1 [dec] tSclntfl_tAdcDbc_gdf32 80.000 °C tScIntl_tâdcPrintedCircuitoard_gdf32 80.000 °C uSelntfl_uAdc1¥2_gdf32 1.200 V

5.000 V 0.000 V 12.000 V 1.200 V wScintfl_SteeringAngle_gdf32 0.000 ° wSclntfl_TorsionBarTorsion_gdf32 0.000 ° xSclntfl_GearRatio_gdf32 30.710 [dec]

DiagConnl DiagConnl_ StorageMemory_gas[4|.Mo DiagConnl_StorageMemory_gas|5].Mo DiagConnl_StorageMemory_gas|5].

DiagConnl_StorageMemory_gas|7].Mo DiagConnl_ StorageMemory_gas|7] gas[0J.MonitorID.

DiagConnl_StorageMemory_gas[0].MonitorStatus DiagConnl_ StorageMemory_gas[1].MonitorID DiagConnl_ StorageMemory_gas[1].MonitorStatus DiagConnl_ StorageMemory_gas|2.MonitorlD DiagConnl_StorageMemory_gas|2].MonitorStatus DiagConnl_ StorageMemory_gas|3|.Moni

Value MONID_DF ZFLSFLAGS ^ HL_MONITOR_STATUS_PASSED out of range HL_MONITOR_STATUS_PASSED out of range

HL_MONITOR_STATUS_PASSED out of range

HL_MONITOR_STATUS_PASSED out of range

HL_MONITOR_STATUS_PASSED out of range

HL_MONITOR_STATUS_PASSED out of range

HL_MONITOR_STATUS_PASSED out of range

Hình 3-3: Giao diện chính phần mềm Softcar es Time: 6:59:05 AM

Giao dién chinh cua phan mềm duoc thé hiện như trên Hình 3-3, gồm một bảng điêu khiên và các cửa sô chứa các thông sô vê hệ thông của bộ đánh lái, một sô thông số quan trọng như: e EcuState: trạng thái của ECU (khởi tạo, bình thường, lỗi, ) e SteeringAngle: góc quay của tay lái (nếu xe hoạt động bình thường thì khi khởi động phải bằng 0) e_ TorsionBarTorsion: góc quay của thanh đòn được điều khién bởi ECU (bang

0 khi vừa khởi động) e Không có bat kỳ lỗi nào xuất hiện với trang thái FAILED ở cửa số2

Blackboard-Control Variable Count Access | Display Info 5061

(` Script © Generator € Stimuli ˆ Equatio { Trace

Run Stop Config Status |Sleep File x

Hình 3-4: Bảng điều khién phần mềm Softcar

Hình 3-4 thê hiện bảng điêu khiên của phân mêm, bảng điêu khiên sẽ có một sô chức năng va thông sô như sau: e Các nút điều khiến như tiếp tục, tam dừng dừng phần mềm; nhảy một chu kỳ hoặc một số chu kỳ biết trước (1 chu ky = 0.5ms). e Breakpoint: dùng dé dat diéu kién tam dừng cho phan mềm khi một biến số nào đó đạt đến giá trị mong muốn. e Cycle count: số chu kỳ mà phần mềm đã chạy từ lúc khởi động. e Variable Count: tổng số biến số của phần mềm.

Phần mềm sẽ hoạt động dựa trên phương thức truyền nhận được thực hiện bởi

CAN: e Giá trị của các Bus thông qua CAN được truyền đến lớp BSW sau đó đến

36 e Tai RTE, các giá tri của Interface đóng vai trò Input được gan giá trị phù hợp với các giá trị của Bus tương ứng trước khi được gửi đến lớp

Application. e Tại lớp Application, các giá tri Input thông qua nội suy được định nghĩa bởi các tập tin thực thi sẽ khiến cho các Interface Output thay đổi giá trị tương ứng.

Phần mềm Softcar được sử dụng với mục đích chính là đánh giá tính chính xác của việc truyền nhận dữ liệu trong hệ thống Source thông qua các lớp BSW, RTE cùng với chuẩn giao tiếp CAN: e Thực hiện việc thay đôi giá tri của các Bus đầu vào và kiểm tra giá tri của các Interface tương ứng cho ta biết được kết quả về tính chính xác của

CAN. e Với các giá trị Interface Input tương ứng, kiểm tra Output cho ta được kết quả về tính chính xác của hệ thống.

Việc đánh giá sẽ được thực hiện bởi một quy trình kiêm thử băng các Test-Case cho từng Component Khách hàng (thường là Software Analyzer của công ty đối tác) sẽ là người cung cấp một hệ thống các yêu cầu phần mềm (Requirement), dựa vào đó Tester sẽ tạo các Test-Case và chạy trên mô hình phần mềm vừa được xây dựng xong.

Nếu kết quả kiểm thử phát sinh lỗi về phần mềm, tiến hành sửa lỗi và biên dịch lại chương trình.

Chương 4 KIEM THU VÀ ĐÁNH GIÁ Ở chương này, em sẽ thực hiện việc kiểm thử phần mềm được xây dựng ở Chương

3 và đánh giá kết quả kiểm thử đó.