⾞載ソフトウェアプラットフォームの動向と aptjの取り組み...autosar:...

⾞載ソフトウェアプラットフォームの動向とAPTJの取り組み

APTJ(株) 代表取締役会⻑・CTO／名古屋⼤学未来社会創造機構教授

⾼⽥広章

カーエレクトロニクス技術展2019年1⽉17⽇

⾃⼰紹介•  本⽇の⽴場

–  APTJ株式会社代表取締役会⻑・CTO•  本務

–  名古屋⼤学未来社会創造機構教授–  名古屋⼤学⼤学院情報学研究科情報システム学専攻教授／

附属組込みシステム研究センター⻑•  その他の役職 (主なもの)

–  TOPPERSプロジェクト会⻑–  ⾞載組込みシステムフォーラム (ASIF) 会⻑–  SIP⾃動⾛⾏システム地図構造化タスクフォース主査

•  研究分野–  (組込みシステム向け) リアルタイムOS–  リアルタイム性解析とスケジューリング理論–  機能安全技術，組込みシステムのサイバーセキュリティ–  ⾞載組込みシステム，ダイナミックマップ

1Copyright © 2019 APTJ Co., Ltd. All rights reserved.

TOPPERSプロジェクト–  ITRON仕様の技術開発成果を出発点として，

組込みシステム構築の基盤となる各種の⾼品質なオープンソースソフトウェアを開発するとともに，その利⽤技術を提供組込みシステム分野において，Linuxのように広く使われるオープンソースOSの構築を⽬指す!

•  プロジェクトの狙い–  決定版のITRON仕様OSの開発–  次世代のリアルタイムOS技術の開発–  組込みシステム開発技術と開発⽀援ツールの開発–  組込みシステム技術者の育成への貢献

•  プロジェクトの推進主体–  産学官の団体と個⼈が参加する産学官⺠連携プロジェクト–  2003年9⽉にNPO法⼈として組織化


← ほぼ完了

H-IIB（JAXA)

エスクード (スズキ)

Cell3iMager duos(SCREEN

ホールディングス)

スカイラインハイブリッド (⽇産)

TOPPERSの開発成果物の主な利⽤事例


SoftBank 945SH

（シャープ） PM-A970(エプソン)

IPSiO GX e3300 (リコー)

UA-101 (Roland)

OSP-P300(オークマ)

名古屋⼤学組込みシステム研究センター (NCES)•  設⽴⽬的

–  組込みシステム分野の技術と⼈材に対する産業界からの要求にこたえるために，組込みシステム技術に関する研究・教育の拠点を，名古屋⼤学に形成

•  活動領域（スコープ）–  ⼤学の技術シーズを実現/実⽤化することを指向した研究–  プロトタイプとなるソフトウェアの開発–  組込みシステム技術者の教育/⼈材育成

•  主な研究プロジェクト–  AUTOSAR Adaptive Platform（A2Pコンソーシアム）–  AUTOSARツールチェーン（APTOOLコンソーシアム）–  ダイナミックマップ（DM2.0コンソーシアム）–  宇宙機向けソフトウェアプラットフォーム–  ⾞載組込みシステムのセキュリティ強化技術

4

☞ http://www.nces.is.nagoya-u.ac.jp/

Copyright © 2019 APTJ Co., Ltd. All rights reserved.

AGENDA•  ⾞載組込みシステム開発の現状と課題•  SPF導⼊の意義とAUTOSAR

–  SPF導⼊の意義，標準化の意義，分類と標準–  AUTOSARとは？，SPFの使い分け–  AUTOSAR CPの概要，利⽤状況，市場動向–  AUTOSARの最近の動き，AUTOSAR CP R4.4.0

•  APTJの設⽴経緯と取り組み–  APTJの設⽴経緯と沿⾰，エコシステム，会社概要–  APTJの強み，APTJの活動⽅針（第1フェーズ）

•  Julinar SPFの概要–  Julinar SPFの正式販売を開始，Julinarの特徴–  Julinar SPFのライセンス形態，利⽤状況，開発計画

•  おわりに–  APTJが⽬指すもの


6

⾞載組込みシステム開発の現状と課題


⾞載組込みシステムの現状と動向•  ⾞載制御システムの⾼度化（⾃動運転登場前から）

–  ⾃動⾞に対する新しい付加価値の多くが，電⼦制御/コンピュータ/ソフトウェアで実現

–  コンピュータを活⽤することで，軽量化やコストダウンが可能になる場合も

–  統合制御システム/サービス（複数のECUの協調/連携により提供するサービス）が増加

⇒ ⾞載組込みシステム/ソフトウェアが著しく複雑化•  ⾃動運転に向けての組込みシステムの変化

–  機能の急速な⾼度化（⼿⾜の電⼦化/コンピュータ化から頭脳のコンピュータ化へ），ソフトウェアのますますの複雑化

–  新しい技術（AI，機械学習，Deep Learning）の導⼊–  外部接続の拡⼤，セキュリティ上の課題が広がる–  急拡⼤する性能要件，扱うデータ（種類，量）の増加–  安全性の考え⽅の変化（フェールオペレーショナルへ）


⾞載組込みソフトウェア開発の課題•  ディペンダビリティの確保/向上

–  システムの⼤規模化により，設計品質，特にディペンダビリティ（信頼性，安全性，セキュリティ，…）の確保が困難に

–  機能安全規格（ISO 26262）への対応が必須に–  サイバーセキュリティの確保/強化が⼤きな課題に

•  設計⽣産性の向上（開発の効率化）–  システム/ソフトウェアの複雑化や品質要求により，設計⽣

産性が低下•  ECUの数の増加，ネットワーク構成の複雑化

–  コストと設置スペースの増⼤，最適設計が困難に•  急拡⼤する性能要件，扱うデータの増加への対応•  新しい技術（機械学習等）をどのように導⼊するか？その背景にある深刻な問題•  ⾞載組込みシステム技術者 (⼈財) 不⾜


課題に対するアプローチ•  ディペンダビリティの確保/向上

–  機能安全規格（ISO 26262）やセキュリティ規格（SAE J3061）への対応

–  トップダウンな設計コンセプト（安全コンセプト，セキュリティコンセプト）とアーキテクチャの構築

–  ⾞載組込みシステムに向いたセキュリティ強化技術の開発/導⼊

•  設計⽣産性の向上（開発の効率化）–  ソフトウェア開発プロセスの地道な改善–  設計抽象度を向上させるためのモデルベース開発–  設計資産の “良い” 再利⽤を可能にするためのプロダクトラ

イン開発とコンポーネントベース開発–  アプリケーション開発底上げのためのプラットフォームと，

その共通化・標準化（プラットフォームベース開発）–  仮想環境（シミュレータ）による検証の効率化


課題に対するアプローチ続き•  ECUの数の増加

–  ECU統合は徐々に（確実に）進⾏する–  プラットフォームの共通化・標準化が前提に–  パーティショニング技術が重要に

•  急拡⼤する性能要件への対応–  新しいプロセッサ技術（マルチ/メニーコア，GPU，FPGA）

の導⼊–  それを使いこなせるソフトウェアの構成/開発技術

•  ネットワーク構成の複雑化，扱うデータの増加への対応–  新しい⾞載ネットワーク技術（CAN FD，⾞載Ethernet）の

導⼊–  新しい通信プロトコル（SOME/IP，DDSなど）の導⼊

•  新しい技術をどのように導⼊するか？–  新たなアライアンス，オープンイノベーション


11

SPF導⼊の意義とAUTOSAR


SPF導⼊の意義•  プラットフォームとは？

–  アプリケーションシステム開発の基盤となる部分ü プラットフォーム＝ハードウェアPF＋ソフトウェアPFü ソフトウェアPF（SPF）＝OS＋ミドルウェア

! ⾃動⾞分野では，⾞台の意味と区別するために，電⼦プラットフォームと呼ぶ場合も多い

•  SPF導⼊の意義 = 開発の効率化–  再利⽤性の向上（開発の重複の排除）

ü アプリケーションソフトウェアの再利⽤ü SPF⾃⾝の再利⽤

–  新機能/新技術の容易な導⼊ü セキュリティ機能（暗号化，MAC，鍵交換，HSM等）ü 新しいネットワーク技術，通信プロトコルü マルチ/メニーコア

–  設計（機能配置）の柔軟性の確保ü システム構成の最適化，ECU統合


SPFの標準化の意義•  前スライドに挙げたSPF導⼊の意義は，業界内での標準

化によりその意義が増す•  SPFの独占/寡占の回避

–  特定ベンダのSPF製品に縛られることを避けることは，コスト最適化の上で重要

–  SPFは，独占/寡占が起こりやすい分野ü ソフトウェア（⼀般）は製造設備が不要，製造コストがほぼゼロü アプリケーションソフトウェアの再利⽤性/流通性が鍵に

–  SPFの（実質的な）独占/寡占は，独占/寡占したベンダの⼒を極めて強くする

–  ⾃動⾞業界がリソースをかけてAUTOSARを推進する理由•  ソフトウェア構築⼿順の標準化

–  ⾃動化（ツール化）が促進される–  分散開発（OEMとサプライヤの間）が容易に

•  技術者の確保/育成


⾞載組込みシステムのSPFの分類と標準•  ⾃動⾞制御システムのためのSPF

–  AUTOSAR Classic Platform（CP）仕様がデファクト標準として広く使われている

•  IVI（In-Vehicle Infotainment）のためのSPF–  各種のSPFが使⽤されている–  以下の標準化活動が動いている

ü AGL（Automotive Grade Linux）ü GENEVI

•  ⾃動運転システムのためのSPF–  まさに開発競争中–  現状では，以下のSPFが標準として有⼒

ü AUTOSAR Adaptive Platform（AP）ü ROS（Robot Operating System），ROS2ü Autoware（ROS上に構築）

•  [番外] ⾃動⾞IoTのためのSPF


AUTOSARとは？•  ⾃動⾞，⾃動⾞部品，エレクトロニクス，半導体，ソフ

トウェア企業によるグローバルパートナーシップ–  2003年に設⽴．ソフトウェアの複雑性を軽減するために，

ソフトウェア基盤（infrastructure）の業界標準を作成•  コアパートナー（2019年時点）

•  2つのプラットフォーム仕様の標準化を推進–  制御システム向けのClassic Platform (CP)仕様（最新は

R4.4.0，2018年10⽉にリリース）は，100を超えるソフトウェア仕様書とほぼ同数の関連ドキュメントなどで構成

–  ⾃動運転システム向けのAdaptive Platform (AP) 仕様は開発フェーズ（最新はR18-10）．並⾏してリファレンス実装が進む

–  CPとAPの共通部分（プロトコル仕様など）を，AUTOSAR Foundation（FO）として分離


BMW Daimler PSA Peugeot CitroenBosch Ford トヨタ⾃動⾞Continental GM Volkswagen

SPFの使い分け


AUTOSAR: “Explanations of Adaptive Platform Design”, R17-10より

Explanation of Adaptive Platform Design AUTOSAR AP Release 17-10

11 of 51 Document ID 706: AUTOSAR_EXP_PlatformDesign - AUTOSAR Confidential -

Figure 2-1 Exemplary deployment of different platforms

Figure 2-2 Exemplary interactions of AP and CP

•  CP，AP，Non-AUTOSARを使い分けていくことが想定されている

AUTOSAR CPとAPの技術的な違い•  下の表から，CPとAPでは，適⽤対象のアプリケーショ

ン（ECU）のイメージが違っていることがわかる


M. Bechter: “AUTOSAR Adaptive Platform – Key concepts and development process,” 9th AUTOSAR Open Conference（2016）を独⾃に⽇本語訳

AUTOSAR Classic Platform AUTOSAR Adaptive PlatformOSEKベース POSIX（PSE51）ベースROMからコードを直接実⾏アプリケーションは不揮発メモリか

らRAMにロードされるすべてのアプリケーションが1つのアドレス空間を共有（安全性のためにMPUを使⽤）

各アプリケーションが⾃分の（仮想）アドレス空間を持つ（MMUを使⽤）

シグナルベースの通信（CAN，FlexRay）に最適化

サービス指向通信

タスク構成が固定複数の（動的な）スケジューリング戦略をサポート

AUTOSAR CPの標準化領域•  ソフトウェアアーキテクチャ

–  ソフトウェアプラットフォーム（SPF）の構成–  RTE仕様–  BSWモジュール（OS，デバイスドライバ群，ミドルウェア

群）毎のインタフェース（API）仕様•  ⽅法論とテンプレート

–  アプリケーションシステムの構築⼿順–  ⼯程間で受け渡すデータの標準化

•  アプリケーションインタフェース–  SW-C（アプリケーションシステムを構成するソフトウェア

部品）間で受け渡すデータのカタログ–  初期は，SW-Cのインタフェースそのものの標準化を⽬指し

たが，断念（競争領域で標準化になじまない）


AUTOSARアプローチ（AUTOSAR CP）•  アプリケーションシステム

を，Virtual Functional Busで接続されたソフトウェア部品（SW-C）群の形で論理的に記述

•  各SW-CをECUにマッピングし，ECUの構成ファイルを作成（現時点では⼿動で作成，ツールにより⽀援）

•  その際に，ECU記述とシステム制約記述（処理の時間制約など）を参照

•  SPFは，RTEとBSWモジュールで構成される


AUTOSAR Virtual Function Bus 4.3.0より

Virtual Functional Bus AUTOSAR CP Release 4.3.0

10 of 104 Document ID 056: AUTOSAR_EXP_VFB - AUTOSAR Confidential -

ECU I

Virtual Functional Bus

AUTOSAR SW-C 1

AUTOSAR SW-C 2

AUTOSAR SW-C 3

AUTOSAR SW-C n...

ECU II

AUTOSAR SW-C 1

AUTOSAR SW-C3

AUTOSAR SW-C 2

ECU n

AUTOSAR SW-C n

RTEBasic

Software

RTEBasic

Software

RTEBasic

Software

...

System Constraint DescriptionECU

Descriptions

Tool Supporting development of SW components

Gateway

SW-CDescription

SW-CDescription

SW-CDescription

SW-CDescription

ECU Description

ECU Description

Flex Ray CAN

Figure 2.2: Detailed view on the activity “Configure System”

In AUTOSAR, an application is modeled as a composition of interconnected components. This is illustrated in the top half of Figure 2.2 (labeled “VFB view”). The “virtual functional bus” is the communication mechanism that allows these components to interact. In a design step called “Configure System”, the components are mapped on specific system resources (ECUs). Thereby, the virtual connections between the components are mapped onto local connections (within a single ECU) or on network-technology specific communication mechanisms (such as CAN or FlexRay frames). Finally, the individual ECUs in such a system can be configured. The concrete interface between the individual components and between the components and the Basic Software (BSW) [5][4] is called the Run-Time Environment (RTE) [7] A component encapsulates complete or partial automotive functionality. Components consist of an implementation and of an associated formal software-component description (defined in the “Software Component Template” specification [6]). The

AUTOSAR CPの構成•  RTE (Runtime Environment)

–  AUTOSARプラットフォームの最⼤の特徴•  BSW (Basic Software)

–  数多くのモジュールで構成 (下の図でも網羅していない)


AUTOSAR Layered Software Architecture 4.2.2より- AUTOSAR Confidential - Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture 71

Not all modules are shown here

Architecture Overview of Modules – Implementation Conformance Class 3 - ICC3

page

id: 9

dfc8

Complex Drivers

Microcontroller

AUTOSAR Runtime Environment (RTE)

Microcontroller Drivers Memory Drivers I/O Drivers

I/O Hardware Abstraction

Memory Hardware Abstraction

Memory Services System Services

Onboard Device Abstraction

Communication Drivers

Communication Hardware Abstraction

Communication Services

Application Layer

Port

Adc

Dio

Pw

m

Icu

Ram

Tst

Can

Fls

Wdg

Lin

Mcu

Fr

Gpt

Spi

MemIf

Driver for ext.

I/O ASIC

Driver for ext.

ADC ASIC

WdgIf

Tp C

om

Nm

IpduM

Nm If

ext. Drv Trcv.

NvM

AU

TOS

AR

OS

PduR

This figure shows the mapping of basic software modules to AUTOSAR layers

I/O Signal Interface

Ea Fee

EcuM

Eep

Eth

Dcm

Dbg

Xf xxx Interface

FlsTst

CorTst

SM

Ocu

FiM

WdgM

Det

Dem

Com

M

Dlt

StbM

Bsw

M

Csm

Tm SecO

C

AUTOSAR CPの構成続き•  各階層の役割! ハードウェアの違いを吸収するソフトウェアを局所化するこ

とで，ソフトウェアの再利⽤性を上げることが可能–  マイクロコントローラ抽象化層（MCAL）

ü マイコンの違いを吸収．デバイスドライバ–  ECU抽象化層

ü ECU（マイコンの周辺回路）の違いを吸収–  サービス層

ü ハードウェアに依存しない⾼レベルサービス–  アプリケーション層：SW-C

ü ECUの外側（例：センサ）の違いを吸収するモジュールはSW-Cとして実現

•  SPFの範囲–  AUTOSARのアーキテクチャ上は，RTEとBSWモジュールが

SPFということになるが，SW-Cの⼀部もSPFと捉えて良い


AUTOSAR CPの技術的課題•  ⼤きいオーバヘッド

–  実⾏時オーバヘッドが⼤きく，ECUのコストアップに•  機能安全への対応が⾮効率

–  機能安全への対応が後付けで，⾮効率的•  マルチコアへの対応が不⼗分

–  マルチコア向け拡張は，まだ⼤きい改良が必要•  完成度の低い仕様

–  曖昧な仕様や不整合が数多く残っている•  難しいインテグレーション

–  様々なしわ寄せがインテグレーション作業に集中–  ツールによる⽀援がまだまだ不⼗分

•  技術を理解している技術者の不⾜（技術的課題ではないが）–  上記の課題克服のためには，AUTOSARの技術を正しく理解

している技術者が必要だが…22Copyright © 2019 APTJ Co., Ltd. All rights reserved.

AUTOSAR CPの利⽤状況•  AUTOSARの中⼼メンバである欧州OEMやサプラ

イヤが，AUTOSAR CPの利⽤を牽引– 数年前から，AUTOSAR CPの利⽤が，主要欧州OEMの

調達条件になっている (ECUの⽤途にもよる)– 国内サプライヤは，欧州OEM対応でAUTOSARを使⽤

してきた (使わざるをえない)•  国内でも，最近になり，AUTOSAR CPを使う⽅向

性を出すOEMが増えてきた–  OEMによる温度差・⽅針の違いが⼤きい

•  ⽶国OEMもAUTOSAR CPを使う⽅向⇒ AUTOSAR CPが⾞載制御システム向けSPFのデ

ファクト標準になっていると⾔える状況


AUTOSAR CPの市場動向•  AUTOSAR CPの国際的な有⼒ベンダは次の通り

ü Vector（ドイツ）… 独⽴系ソフトウェア企業ü Elektrobit（グループ本社はフィンランド，AUTOSAR関係

はドイツの企業を買収）… 2015年5⽉にContinentalが買収ü Mentor Graphics（⽶国，AUTOSAR技術はスウェーデンの

企業から買収）… 有⼒なEDAベンダ，2016年11⽉にSiemensが買収

ü ETAS（ドイツ）… Boschの⼦会社ü KPIT（インド）… 独⽴系ソフトウェア企業

•  国内においては，複数の企業連合によりAUTOSAR CPを開発・販売する活動／企業が⽴ち上がっているü SCSK+数社（QINeS-BSW）… 2014年⽴ち上げü APTJ … 2015年設⽴ü オーバス（デンソー，イーソル，NCOS）… 2016年設⽴


今後の予測と我々の問題意識•  今後の予測

–  国内の3陣営が頑張らないと，近い将来に，⾞載制御システム向けSPFを有⼒ (海外) 企業に寡占されてしまう可能性が⾼い

•  海外企業に寡占されることによる問題–  開発速度が律速されるおそれ–  ノウハウが活⽤できなくなる/流出する/揮発するおそれ–  コストの上昇，交渉⼒の弱さがハンディになる可能性

•  我々の問題意識–  SPFを海外メーカに寡占されることにより，我が国の⾃動⾞

産業 (まずはサプライヤ，次いでOEM) のものづくり⼒の低下につながるのでは？

–  SPFが海外製になることで，その上で動作するアプリケーションも海外で開発した⽅が有利になり，国内の⾞載組込みソフトウェア産業が縮⼩するのでは？


AUTOSAR APの策定経緯•  ADAS・⾃動運転の実現に向けて，新しい要求にこたえ

るSPFが必要という認識•  ADAS・⾃動運転を狙った新しい仕様として，

AUTOSAR Adaptive Platform（AP）を策定することに–  従来のAUTOSARプラットフォーム（AUTOSAR CPと改

名）とは考え⽅が⼤きく異なり，CPの拡張では限界がある–  標準化を加速するため，仕様策定とリファレンス実装の開発

を並⾏に進める（AUTOSARの活動モデルの変更）•  CPとの技術上の最⼤の違い

–  静的から計画された動的（planned dynamics）へü ソフトウェアの開発とインテグレーション時には，リ

ソースと通信の動的管理により開発を容易にし，製品提供の時点では，動的な振る舞いを制限する

ü 開発効率化に重点が置かれている


AUTOSAR APのアーキテクチャ•  アーキテクチャの論理ビュー


AUTOSAR: “Explanations of Adaptive Platform Design”, R17-03より

Explanations of Adaptive Platform Design AUTOSAR AP Release 17-03

12 of 31 Document ID 706: AUTOSAR_EXP_PlatformDesign - AUTOSAR Confidential -

3 Architecture 3.1 Logical view 3.1.1 ARA Figure 3-1 AP architecture logical view shows the architecture of AP. The Adaptive Applications (AA) run on top of ARA, AUTOSAR Runtime for Adaptive applications. ARA consists of application interfaces provided by Functional Clusters, which belong to either Adaptive Platform Foundation or Adaptive Platform Services. Adaptive Platform Foundation provides fundamental functionalities of AP, and platform standard services called Adaptive Platform Services. Any AA can also provide Services to other AA, illustrated as Non-platform service in the figure. The interface of Functional Clusters, either they are those of Adaptive Platform Foundation or Adaptive Platform Services, are indifferent from AA point of view – they just provide specified C++ interface, or any other language bindings AP may support in future. There are indeed differences under the hood. Also, note that underneath the ARA interface, including the libraries of ARA invoked in the AA contexts, may use other interfaces than ARA and it is up to the design of AP implementation.

Figure 3-1 AP architecture logical view

Be aware that Figure 3-1 AP architecture logical view contains Functional Clusters that are not part of initial releases of AP, to provide a better idea of overall structure.

AUTOSARの最近の動き•  2018年10⽉に，CP R4.4.0，AP R18-10，FO R1.5.0

がリリースされた–  3つの仕様が同じタイミングでリリースされるのは初めてで，

CPFOAPで整合がとれたバージョン（とされている）–  APは，当初は2018年10⽉までが「開発フェーズ」とされて

いたが，延⻑された模様•  Adaptive Platform Demonstrator（APのリファレンス

実装）も同時期にリリース•  今後，CPとAPの標準化活動が統合される計画

–  これまでは，それぞれの標準化チームがあり，独⽴に活動していた

–  両SPFで共通のトピックや整合性を取る必要があるトピックが増えている


AUTOSAR CP R4.4.0•  様々な新コンセプトが導⼊されている•  R4.4.0で新規に導⼊された主なコンセプト

–  ASAM Units–  ARTI (AUTOSAR Run-Time Interface)–  RTE Implementation Plug-ins–  LIN Slave Support–  Formal Model Query and Blueprint Derivation

Mechanisms–  Bus mirroring –  Security Extensions–  MCAL Multicore Distribution–  LET (Logical Execution Time)–  Transport Layer Security (TLS)–  Extended Serialization for Data Structures in SOME/IP

with tag / length / value (TLV) encoding


ARTI（AUTOSAR Run-Time Interface）•  ビルド／デバッグ／トレースツールとAUTOSARと

のインタフェースとなる仕様– コンポーネント内部の状態（例：Osタスクの状態）を

デバッグツールが取り出すための⽅法を，AUTOSARツールからデバッグツールに引き渡す⽅法の定義

– コンポーネントの実⾏トレースを取るために，コンポーネント内に埋め込んでおくべきマクロの定義

•  ORTI（OSEK Run-Time Interface）のコンセプトを，AUTOSARに導⼊したもの

•  R4.4.0では「ドラフト仕様」の段階– 今後のバージョンで，仕様変更がありうることを⽰し

ている– 現状は，Os仕様にのみ取り込まれている


Copyright © 2019 APTJ Co., Ltd. All rights reserved. 31

APTJの設⽴経緯と取り組み

APTJの設⽴経緯•  APTJの必要性

–  AUTOSAR CPが国際標準になる流れの中で，⾞載制御システム向けのSPFが海外製だけになるおそれ

–  名古屋⼤学におけるコンソーシアム型共同研究 (APコンソ) の活動だけでは不⼗分という認識

•  設⽴までの経緯–  2014年夏頃から，APコンソを拡⼤する⽅策を模索

ü 技術組合など，複数の形態を検討ü 株式会社の形で活動するのがベストと判断

–  2015年にかけて，共同開発サプライヤ，パートナーソフトウェア企業と継続的に協議ü パートナーソフトウェア企業から出資を，共同開発サプ

ライヤから共同開発費を受けるスキームに–  2015年9⽉に会社を設⽴し，10⽉から活動を開始


APTJのエコシステム


APTJ

パートナーソフトウェア企業

ヴィッツ永和システムマネジメント

キヤノンITソリューションズ

サニー技研東海ソフト富⼠ソフト菱電商事

（2019年1⽉時点）

その他のサプライヤ/

OEM

共同開発サプライヤ豊⽥⾃動織機ジェイテクト

東海理化電機製作所スズキ(内製部⾨)

＜他1社 (⾮公表)＞（2019年1⽉時点）

TOPPERS

オープン化

APコンソ

研究開発成果

開発成果

ライセンス販売

サブライセンス権

ライセンス

サポート

出資

開発技術者

共同開発費

サポート

サポート

APTJの設⽴以降の沿⾰•  設⽴以降の沿⾰

–  2015年10⽉1⽇：APTJ設⽴をプレス発表．活動開始–  2015年12⽉：第３者割当増資の実施．共同開発サプラ

イヤ3社との契約締結をプレス発表–  2016年5⽉：２回⽬の第３者割当増資の実施 (資本

⾦：499百万円，資本準備⾦同額)．共同開発OEMとの契約締結をプレス発表

–  2016年11⽉：製品／サービス名を発表–  2017年2⽉：AUTOSARプレミアムパートナーに–  2017年8⽉：本社を移転–  2017年7⽉,10⽉：３回⽬の第３者割当増資の実施 (資

本⾦：約1011百万円，資本準備⾦同額)–  2017年11⽉：Julinar SPFの先⾏販売を開始–  2018年10⽉：Julinar SPFの正式販売を開始


APTJ会社概要設立年月日 2015年9月16日所在地名古屋市中村区平池町四丁目60番地12 グローバルゲート22階役員代表取締役会長 CTO 高田広章

代表取締役社長高嶋博之専務取締役桑木肇社外取締役三木誠一郎社外取締役竹中一起取締役（監査等委員）浅野真弘取締役（監査等委員）⽥島和憲取締役（監査等委員）加藤⻯

資本金 1,011百万円（平成31年1月1日現在）パートナーソフトウェア企業（五十音順）

株式会社ヴィッツ，株式会社永和システムマネジメントキヤノンITソリューションズ株式会社，株式会社サニー技研東海ソフト株式会社，富士ソフト株式会社，菱電商事株式会社

　　


APTJの強み•  技術的な強み

–  TOPPERSプロジェクトと名古屋⼤学における⻑い開発経験と先端的な技術ü リアルタイムOS（特に，パーティショニング技術，マルチ/メ

ニーコア対応）ü 機能安全，セキュリティü 仮想化技術ü ⾃動運転，ダイナミックマップ

–  AUTOSAR技術に対する知験（国内では）•  ビジネスモデル上の強み（エコシステム）

–  ソフトウェア企業によるコンソーシアム型企業ü 特定のOEM/サプライヤの出資を得ていないü サポート⼒（サポート技術者）のスケーラビリティ

–  共同開発サプライヤの存在ü SPF製品に対する要求出しü 最初の採⽤事例 → 実績に


APTJの活動⽅針 (第1フェーズ)•  2つの活動を並⾏して進める

–  AUTOSAR CPに準拠したSPF (Julinar SPF) の開発 (コア資産開発)

–  Julinar SPFを利⽤した共同開発サプライヤのECU開発のサポート

•  コア資産開発の対象–  AUTOSAR SPFの全体を開発対象とする

ü ただし，必要性が低いモジュール／機能は除外するü MCAL (マイコン抽象化層) については別に検討ü AUTOSAR Release 4.2.2をベースとする

–  開発⽀援ツールの対応ü ジェネレータは独⾃に開発ü 上流設計ツールとコンフィギュレーションツールは，他社製

ツール (dSPACE社 SystemDesk等) を活⽤



Julinar SPFの概要

Julinar SPFの正式販売を開始•  2018年10⽉より，Julinar SPFの正式販売を開始•  次の6社のパートナーソフトウェア企業を通して販

売 (五⼗⾳順)ü 株式会社ヴィッツü キヤノンITソリューションズ株式会社ü 株式会社サニー技研ü 東海ソフト株式会社ü 富⼠ソフト株式会社ü 菱電商事株式会社

•  Julinar SPFに対するサポートサービスは，パートナーソフトウェア企業が提供．APTJはそれを⽀援– ⼀部のサービスはAPTJが直接提供


Julinarの特徴•  AUTOSAR仕様に忠実な設計

–  メモリ効率や処理速度の向上に配慮しつつ，AUTOSAR仕様に忠実に設計 (機能のサブセット化は実施)

•  名古屋⼤学の⻑年の研究成果をベースに開発–  ⾼い実⾏性能のOS (実⾏性能と保守性のバランスを考慮)–  マルチコア対応などの⾼度な開発要求にも対応可能

•  サプライヤの要求を満⾜する品質–  サプライヤとの共同開発により，サプライヤの品質要求に合

致し，要望を反映したソフトウェアを提供•  機能安全ASIL-D対応

–  ISO 26262に基づく機能安全プロセスを構築•  パートナーソフトウェア企業と共に充実したサポート体

制を構築•  OEMの個別仕様への対応要求にも対応

–  特定のOEMの個別仕様に対応した開発も進⾏中


販売するBSWモジュール


※ ⾚点線枠内のモジュールは，AUTOSAR CP R4.3.Xに準拠

プリプロト開発：Automotive SPICE対応の開発プロセスによる品質確保を⾏っていないもの

※ MCALは半導体メーカ製を利⽤いただくのが基本

Julinar SPFの機能安全対応⽅針•  SPFの中で機能安全対応が必要なBSWモジュールを特定

–  Os, RTE, WdgM, WdgIf, E2E, CRC•  安全要求の設定

–  上記モジュールの機能要求を安全要求と置く–  それに加えて，異なるASILソフトウェアの混在を可能にす

るFreedom From Interference (FFI) が実現できることを安全要求とする

•  開発プロセス–  Automotive SPICEおよびISO 26262 ASIL-Dに対応したプ

ロセスで開発•  機能安全対応の現状

–  WdgM, WdgIf … 対応済み–  Os, RTE … 機能 (ユースケース) を限定して対応済み，対応

機能を徐々に増やしていく–  E2E, CRC … 対応中


Julinar SPFのライセンス形態•  開発ライセンス

–  Julinar SPFをECU開発に利⽤するためのライセンス–  ECUの開発開始時に購⼊いただく

•  製品ライセンス–  Julinar SPFをECU製品に組み込むためのライセンス–  ECUを製品化するまでに購⼊いただく–  Julinar SPFのランタイムコードのソースコードを提供

(ソースコードの改変も可能)•  ソースコードライセンス

–  Julinar SPFを (特定の製品開発ではなく) 研究開発⽬的や教育⽬的に利⽤するためのライセンス

•  その他のライセンス形態についても応相談


Julinar SPFの利⽤状況•  Julinar SPFを使⽤した複数種類 (対象OEMも複

数) のECU開発が進⾏中–  Julinar SPFを使⽤した最初のECUは，2019年〜2020

年に市販の⾃動⾞に搭載される予定•  研究開発・⼈材育成での利⽤

– ⽇本⾃動⾞研究所 (JARI) などが開発を進める⾃動⾞セキュリティ評価⽤オープンプラットフォーム「Security Testbed System」に採⽤

– 名古屋⼤学におけるコンソーシアム型共同研究で利⽤


Julinar SPFの現在/今後の開発計画•  進⾏中の開発

– サプライヤとの共同開発を継続実施，サプライヤからの個別開発依頼にも対応

– 未完成のBSWモジュールの開発・品質確保ü セキュリティ機能 (暗号化スタック，SecOC)ü ダイアグスタック（Dem，Dcm)

–  Julinar OSの各種のマイコン (プロセッサ) への対応ü ARM Cortex-Rü Infenion Tricore

– 特定のOEMの個別仕様に対応したBSWモジュール•  今後の開発計画

– 現時点で未対応のBSWモジュールの開発– マルチコアプロセッサ向けの拡張などなど



おわりに

APTJが⽬指すもの•  第1フェーズ

–  品質が⾼く，⾃由に改変可能で，国内でサポートできるAUTOSAR CP準拠SPFを開発し，国際的に普及させるü 国内でのサポートを考えると，国内で開発するのが望ま

しい（必須ではない）ü AUTOSAR仕様に対して，国内OEM/サプライヤのニーズ

に合致するような解釈/修正を加える! 海外有⼒企業に対抗して⽣き残れることが必須

–  AUTOSAR技術に精通した技術者を育成する! ⾃動⾞産業の競争⼒維持/強化に貢献したい

•  第2フェーズ以降–  我が国から国際標準技術を発信できる企業に! ⾞載組込みシステムの分野において，国際的にトップクラス

の企業に成⻑させていく


⾞載ソフトウェアプラットフォームの動向と aptjの取り組み...autosar:...

Documents