0

私がCでソフトウェアを書くことができるソフトウェア開発者であることを考慮して、Autosarに関連するこの点について提案できますか？

ここで、Cで機能を開発します。この機能は、ECU固有のデータを読み取り、処理して、ECU固有のデータ（変数またはI / O信号の場合があります）を更新する必要があります。

  1. Autosar RTEと仮想機能バスをどのように使用しますか？ソフトウェア開発者には何が使われるのでしょうか？

  2. また、Autosarが「インターフェースの標準化」と言っているように、それはどういう意味ですか？世界中のどこかで同じ機能を開発している場合（私のようにC言語で）、両方がそれらのI / O信号に同じ名前のAPIを使用することを意味しますか？

  3. ユニットテストでRTEはどのように役立ちますか？または、ソフトウェア開発者の観点から、RTEは実際に何をしているのでしょうか。

http://www.autosar.org/gfx/AUTOSAR_TechnicalOverview_b.jpg

私は多くの専門用語を読みました...しかし、ソフトウェア開発者であるため、これらの点は私が知るために重要です。少し説明してもらえますか？

お返事をいただければ幸いです。

4

5 に答える 5

8

そんなに簡単にはいかないと思いますが・・・Autosar SWC（ソフトウェアコンポーネント）を開発されていると思います。移植可能な C モジュールを開発することをお勧めします。それには非常に明確な入力、出力、および要件があります。実行時 (Autosar runnables をチェック)。Autosar ECU には RTOS が含まれているため、モジュールは OS タスクの一部になります。Autosar ECU を構築する段階に来たら、モジュールをラップし、入出力を Autosar 仮想機能バス信号に接続することができます。そのためには、Autosar フレームワークと、おそらく構成ツールが必要になります。これらは複雑で高価です。Cモジュールをテストする通常の方法でモジュールを単体テストします。幸運を。

PS RTE は、ECU BSW の構成とその ECU の System Extract に従って、構成ツールによって自動的に生成される単なる「接着剤」コードです。ラッピングの際に気になります。

于 2012-12-11T09:50:53.777 に答える
2

AUTOSAR SWC と基本ソフトウェアの機能を分割する背後にあるアイデアは、アプリケーション SW の開発をプラットフォームから独立させることです。ご質問にお答えします。

  1. RTE はアプリケーションに信号ベースのインターフェイスを提供するため、他の SW コンポーネント (ECU 間 / ECU 内) が必要なデータを信号の形で提供することを期待し、プラットフォームや通信媒体の種類を気にする必要はありません。
  2. はい、インターフェイス (あらゆる種類の対話) を標準化することにより、ソフトウェア コンポーネントまたは任意の基本ソフトウェア モジュールをSW アーキテクチャに固定できます。さまざまなタイプの AUTOSAR インターフェイスについて詳しくお読みください。
  3. 回答 1 を参照
于 2014-05-23T09:39:32.563 に答える