　実作業の観点では「Preparation→Configuration→Validation→Compile→Link→Run」のステップ^※7）を踏んでいくことになるが、Integrate Software for ECUではLinkまでの部分に対応している。少々長くなるが、その対応関係も含めて以下に書き出す^※8）。

Prepare ECU Configuration

　この段階はPreparation（準備）の段階といえるであろう。必要なものを集め、以降の作業を開始するための起点である。なお、規格では明示されていないが、ECUソフトウェア構築のために必要なBSWの購入手配はここまでに済んでいなければならない。そのためには、必要なBSWの洗い出し、マイコンの入出力端子やハードウェアタイマー、通信チャンネルなどのハードウェアリソース割り当て計画や外部デバイスとの接続方式の計画などを行わなければならない。当然ながら、AUTOSAR BSWに関する知識なしでは、必要なBSWの洗い出しはできないし、安全関連系であればSafety Goalもある程度はっきりしていなければBSWに対する安全関連の要求も特定できない。

・Define Integration Variant
　一般にECUは不揮発メモリ上あるいはハードウェア上の設定により動作を切り替えることが多い。そのバリアント数は時には100を超える。このバリアント情報の設定をいつどこで行うのか、という情報^※9）が必要になる。
・Generate Base Ecu Configuration
　まず、自動車メーカーから提供されるXMLファイルの1つであるECU Extractの完成度を見極めなければならない（一種のValidation）。Diagnostic ECU Extractが提供される場合にはそちらも同様である。XMLレベルのValidationだけではなく、実際に次の工程（Configure BSW and RTE）を実施するのに必要な項目が入力されているか否かを見極め、必要に応じて暫定的に補いかつその内容を上流工程（通常は自動車メーカー）にフィードバックすることが必要となる^※10）。場合によっては、XMLファイルをテキストレベルで修正しなければならなくなることもある（ドイツ語圏の文字と日本語などの他バイト文字の混在が、不適切な文字エンコーディングで行われた場合など）。XML Validationを行うのであればXMLに関する最低限の理解は欠かせない。

Update ECU Configuration

　この段階では、プロジェクトを進めていくときに、ECU ExtractやDiagnostic ECU Extractが更新された場合の対処を行う。

・Define Integration Variant
・Generate Updated ECU Configuration

Configure BSW and RTE

　この段階では、BSWやRTEに対するConfigurationが中心であるが、その設定内容に対するValidationも頻繁に行うこととなる^※11）。また、各項目の設定を進めていくには、かなりの順序制約も存在するが、スクラッチからのインテグレーションを数回繰り返していくうちに習得できる^※12）。なお、RTE / BSW設定といっても、ただ設定項目をクリックしていく単純作業だけではない。AUTOSAR TR Methodologyからは見えにくいのだが、それぞれの項目に対してどのような値を設定するかを検討する作業も含まれる。BSW構成が決まれば自動的に設定内容が決まってしまうようなものもあるのだが、たった1つの項目に対して長い時間を要するものもある。

・Configure Com
　通信関連の基本的な設定の多くは、ECU Extractに含まれる通信マトリクス相当の情報によりほとんどが自動的に設定される（Configure ECUC）。しかし、そのように自動設定できないものも存在する。例えばCAN通信の場合においては、MCAL （CAN）側の設定にてpolling／interruptのどちらを選ぶかなどに左右されながら、Full CAN／Basic CAN objectのどちらを使用するか、pollingなどの周期処理の間隔をどのようにするか、そして、他の処理とのtimingの前後関係をどのようにするかなどを、ECU個別の通信面での要求や他の処理に対するblocking time上限の制約などを考慮しながらこの段階で決めていく。また、そもそもpolling方式では、使用方法によってはイベントの取りこぼしがより発生しやすいため、Network上のSystem Signalのうち、取りこぼして良いものとそうではないものを区別することが必要となる場合もある^※13）。
・Configure Debug
・Configure Diagnostics
　恐らく、最も煩雑な部類の作業の1つとなる。「診断」という言葉で、さまざまな故障検出機能がライブラリ化されているのではないかという誤った期待がもたれることが多いが、BSWがSensor役として完結している場合（例：CAN bus off検出）を除くと、SW-C側でSensor役の処理を実装しなければならない。また、安全要求におけるFTTIなどを考慮しながら実装しなければならないため、BSW側で用意されているメカニズムだけで満足できるのか否かを逐一見極めなければならない。また、生産設備対応機能とも密接に関連するため、ハードウェア開発者や生産技術担当者とも可能な限り早期に成立性検討を行う必要がある。なお、Diagnostic ECU Extractはまだ登場して日が浅く、ODX^※14）などの従来型データフォーマットが使用されることも多い。
・Configure ECUC
　通信関連の基本的な設定の多くは、ECU Extractに含まれる通信マトリクス相当の情報によりほとんどが自動的に設定される。なお、ECU Extractではなく、DBCなどの従来型データフォーマットが使用されることも少なくない。
・Configure IO Hardware abstraction
　IO Hardware abstractionは、ハードウェアには依存しないがMCALには大きく依存するため、MCAL入れ替え時には変更が必要となる。
・Configure MCAL
　恐らく、最も煩雑な部類の作業の1つとなる。設定に当たっては、AUTOSAR全般の知識、上位層BSWからの要求、使用するMCAL実装についての知識、当該マイコンの知識、ならびに、入出力端子やハードウェアタイマー、通信チャンネルなどのハードウェアリソース割り当てに関する知識が必要となる。なお、マイコンメーカー製MCALを使用するのであれば、場合によってはマイコンメーカー側の技術者が上記要件を最もよく満たしている可能性もあるので、その場合には、MCAL設定作業を依頼するのも選択肢の1つである。
・Configure Memmap Allocation
　恐らく、最も煩雑な部類の作業の1つとなる。MemMap.hおよび関連ファイルを、SW-C／BSW構成およびMemory Protection設定に合わせて編集していくこととなるが、ここではC言語というよりも、使用するCompiler Packageの特にLinker設定の知識が必要になる。
・Configure Mode Management
　恐らく、最も難しい部類の作業の1つとなる。ECUごとにVariant切り替えや通信、各種calibration data読み出しなどのそれぞれで初期化処理のdeadline制約が異なるため、初期化シーケンスはその都度新たに組み立て直さなければならなくなることも多い。また、SLEEP、OFFあるいはRESET動作の前の終了準備シーケンスも同様である。近年は、暗電流が航続距離にも直接影響するようになってきているため、SLEEP動作に関しては厳しい要求が求められることも多く、ハードウェア開発者と可能な限り早期に成立性検討を行う必要がある。
・Configure NvM
　恐らく、最も難しい部類の作業の1つとなる。不揮発メモリとして格納すべき情報のサイズ、アクセスタイミング（頻度／回数を含む）、生じた誤りに対する必要な対処が代表的なものとなる。なお、現在のAUTOSAR BSWでは誤り検出機能には対応しているが、誤り訂正はカバーされていない。また、開発中に不揮発メモリマップを変更すると、変更前のデータを読み出せなくなる場合があることには注意が必要である。近年では、開発の早い段階からECUを搭載した車両を世界各地に送り出し実車評価することが多いのだが、通常は不揮発メモリにECUハードウェア個体差調整情報（A／D値のオフセットなど）が格納されており、不揮発メモリマップ変更を含む新ソフトウェアをメールで受け取り書き込んだ後に、それらが読み出せないなどの問題が生じやすいため、早期に不揮発メモリマップを確定させることは極めて重要である。
・Configure OS
　恐らく、最も煩雑な部類の作業の1つとなる（特にISR登録）。なお、RTEでのTask Mapping設定を行うと、RTEの機能実現のためのAlarmやEventなどが自動的に追加されるが、これらの設定はOs単体レベルで自由に変更して良いものではない。これと同様に、他のBSWの設定により設定内容が決まってしまう（依存性を持つ）ものは決して少なくない。
・Configure RTE
　Task Mapping（Runnable Entityの、Taskへの割り付け^※15））や、Data Mapping（Network上のSystem Signalと、Port Data Elementの対応付け）などが対応する。また、排他制御のためのExclusive Area／Critical Sectionの実現方式の設定が必要となるが、排他制御の設計原則を理解していないと、この設定を過不足なく行うことはできない。過剰であればruntime性能が低下し、不足があれば排他制御に失敗し動作に異常を来す。
・Configure Transformer
　E2Eの設定が代表的なものである。
・Configure Watchdog Manager
　Control Flow MonitoringのためのCheck Pointを適切に設定できることが求められるが、例えば自動車メーカーから与えられたSW-C側のCheck Point設定が不適切であるような場合には、自動車メーカー側との調整力が必要となる。特に、これはWatchdogに限った事ではないが、安全要求は多くの場合にハードウェア構造などにも大きく依存するため、変更が必要となる根拠とそれが満たされない場合の結末を論理的に説明し続け、かつその記録を明示的に残すということが一般に求められる。
・Connect Service Component
　これは、ASWにおけるSW-CのService Port PrototypeとBSWの間を、RTEを介して接続する作業である（ASWにおけるSW-CのApplication Port Prototype間をConnectorで接続する作業と類似）。一般に、Diagnostics関連のものに対する煩雑な作業が発生する。
・Create Service Component

Model ECU Timing

　この段階も、BSWやRTEに対するConfigurationの一段階と言える。

・Define ECU Timing
・Generate BSW and RTE
　この段階では、BSWやRTEのCode Generationを行う。
・Generate BSW Configuration Code
・Generate BSW Memory Mapping Header
・Generate Compiler Configuration
・Generate Local MC Data Support
・Generate OS
・Generate RTE
・Generate RTE Prebuild Dataset
・Generate SWC Memory Mapping Header

Build Executable

　この段階では、BSWやRTEだけではなくASWのSW-C群やStart up codeも含めてのBuild（Compile, Assemble, Link）となる。既にAUTOSARレベルでの設定はほぼ終わり、従来と同様のC言語やマイコンレベルでの作業が中心となる。

・Compile ECU Source Code
　いわゆるCompile / Assembleの段階。
・Generate A2L
・Generate ECU Executable
　いわゆるLinkの段階。
・Generate RTE Postbuild Dataset
・Measure Resources

注釈

※7）なお、最後のRun時点でのエラーの解決のために、時にはECU Extractまで戻って修正しなければならないこともある。設定がある程度進むといきなりほぼ完全に動き出すが、それまでは全く動かないものである。動き始めるまではPreparationの段階まで戻ることも多いので、「動き始めるまでの進捗」の把握は、たとえ経験者が作業を行うのであっても、当人でさえ把握しにくいものであることに注意されたい。また、CalibrationはRunの後の段階で行われる。

※8）大項目については、当該規格文書における登場順ではなく、おおよその作業実施順を示した。

※9）例えば、ECUサプライヤ側でのECU製造工程、自動車メーカー側での車両製造工程、販売店など多くの可能性がある。それを明らかにするためには、自動車メーカーやECUサプライヤ双方の生産技術部門からのinputが必要となる。

※10）Validation機能付きのXMLエディタなどを利用し、XML Schemaファイルと整合していることを確認する基本的な工程。

※11）AATで自動的にValidationが行われることも多いが、これは作業性の低下ももたらす。慣れてくると、自動Validationを無効化できるツールの方が好まれる。

※12）読んで覚えるよりも、実際に試し、自らメモを作りながら体で覚えた方がはるかに効率良く進められる。

※13）初回の問い合わせに対する自動車メーカー側からの回答は、ほぼ確実に「原則として取りこぼし禁止」であろう。具体的なケースでの許容を引き出すための議論に持ち込むだけでも相当な苦労が必要になるが、最近は、相手がどれくらい食い下がってくるかを試されることも少なくないようだ。食い下がれるからには、技術力もそれなりにしっかりしているだろう、という仮定に基づく見極めかと思われる。

※14）ODXは本来診断テスター用に制定された規格であり、ECUの開発に必要な情報はあまり充実していない。

※15）Task Mappingの際にRunnableを割り付ける先のOs TaskのPriorityの決定においては、Runnableの処理Deadlineの特定がまずは必要となるが、このような情報が与えられることはまれである。また、デジタル信号処理理論ベースのモデルベース開発ツールからコード生成されたものを使用する場合には、しばしば、周期処理の許容jitter＝±0［ms］という非現実的な要求が行われる場合がある。マイコンやソフトウェアの性質からいっても成立可能性はゼロであるし、そもそもこのような許容誤差なしでの定義の仕方は、工学的には正しいものではない。