ソフトウェア・オーバーA2B – A2Bはオートモーティブ・アプリケーションにおけるSOTAにどのような変化をもたらすか

myAnalogに追加

myAnalog のリソース セクション、既存のプロジェクト、または新しいプロジェクトに記事を追加します。

新規プロジェクトを作成

概要

ソフトウェア・オーバー・ジ・エア(SOTA)には、オートモーティブOEMによる開発と展開が求められる重要な機能として、急速に注目が集まっています。モジュールのアップデート、顧客のサポート、追加機能の収益化などが可能になることから、SOTAを自在に操ることは魅力的な課題となっています。本稿では、オートモーティブ環境においてSOTAが注目されるようになった理由、その展開方法、そして、オーディオおよびインフォテイメント・ネットワークにおいてSOTAを実装するためにA2B®(オートモーティブ・オーディオ・バス)技術をどのように使用できるのか、ということについて述べます。

はじめに

コンスーマが、自分の所有するデバイスのソフトウェア的な複雑さをランク付けするとしたら、そのトップに挙げられるものは何でしょう。ラップトップ? スマートフォン? それともゲーミング・コンソールでしょうか。実は、道路を走っている自動車がこれらのどのデバイスよりも複雑であること、しかもその程度は桁外れに高いということは、多くの人々にとって意外な事実かもしれません。現代の平均的な車には150個もの電子制御ユニット(ECU)が搭載され、1億行に及ぶコードが実行されています。これに対し、F-35ジェット戦闘機が使用するコードは2,500万行未満、Androidオペレーティング・システムでは1,500万行未満、Google Chromeでは1,000万行未満です1

オートモーティブ・アプリケーションで使われるようになったソフトウェアは膨大な量に及ぶため、自動車の様々な場所で用いられている無数のソフトウェアのバージョンとリビジョンを管理し、制御する方法が必要です。SOTAアップデートを利用する自動車関連のメーカーやOEMに生じる利益は、車体に関する軽微な問題の是正から自然災害への対応にいたるまで、広範囲に及ぶことが見込まれます。テスラ社は、2017年9月のハリケーン「イルマ」への対応において、SOTAアップデートの最も広く認識されている応用例の1つを実施しました。このハリケーンがフロリダ州(米国)に迫ったとき、テスラは自社製車両の走行距離延長のロックを解除するSOTAアップデートを発行し、迫り来るハリケーンから避難しようとするオーナーを支援することによって、顧客の要求に応えました2。他のOEMは自社製車両に関るSOTA能力のギャップを露呈し、それが評価の低下につながって顧客の信頼を失うに至ったのです。

自動車のECU数とコード行数のさらなる増加をもたらす自動車の電気化や自動運転技術などの新たなメガトレンドに伴い、自動車のあらゆる領域において信頼性の高い効果的なSOTA機能を確保することの重要性も増しています。

1977年にオールズモービル・トルネードの点火タイミングを制御するために初めてマイクロコントローラが使われて以来、ECUは常に自動車産業の一部を構成してきました3。初期に行われたソフトウェア・アップデートでは、ECUを車体から取り外して再プログラミングを行う必要があり、時間も手数もかかる可能性があるプロセスとなっていました。エンジン・ルームからエンジン制御ECUを取り外す作業は比較的容易かもしれません。これに対し、ラジオ・ヘッドユニットの場合は、ダッシュボード、センターコンソール、その他のトリムなど、様々な部品を取り外す必要があります。車体から取り外した後も、初期のECUはベッドオブネイル・プログラマなどの複雑なツールを使って再プログラミングを行う必要がありましたが、これらのツールは高価で複雑な上に、不安定で取り扱いが難しいものもありました。こうした要因が組み合わさり、初期のECUでは、ソフトウェア・アップデートを発行するよりもユニット自体を別のモジュールに交換してしまう方が、魅力のある選択肢でした。

ソフトウェア・オーバー・ジ・エア

SOTAは自動車産業におけるソフトウェア・アップデートの発展の最先端に位置するものであり、初期のECUから現在の高度にネットワーク化された柔軟なオートモーティブ・インフラストラクチャへの橋渡しとなる存在です。ECUを車体に搭載したまま現場でアップデートできる機能は、オートモーティブOEMにとって魅力的なだけでなく、ますます重要な機能になりつつあります。緊急時に人命を救うことになる機能を必要に応じて迅速に提供するために、OEMがどのようにSOTAを利用することができるのかについては、既に述べました。SOTAに関して最もはっきりしている用途は、必要なときに必要な方法で、OEMが車載ソフトウェアに関する重大な問題に対処できるようにすることです。これによってソフトウェアに関係する車両リコールの必要がなくなり、結果的にコンスーマにとっては所有環境を改善することができ、OEMにとってはリコールのコストを削減することができるので、極めて強力な機能だと言えます。ディーラーに車両を持ち込むことなく、管理された形でソフトウェア・アップデートを行うことができることは、OEMに大きな価値をもたらします。

図1 自動車のライフサイクル

図1 自動車のライフサイクル

SOTAは、このソフトウェア・リコール管理の合理化だけに止まらず、他にも自動車のライフサイクルにおける多くの要素を単純化できる可能性を秘めています。SOTAは生産工程においても利用可能であり、製造を完了して出荷する前に車両のファームウェアに問題がないことを確認できます。車両の納入に要する時間は数日間(例えばOEM国内市場)から数週間(例えば海外市場)までの範囲で異なるため、車両がその目的市場に到着した時点でソフトウェア・アップデートが必要になる可能性があるというのは重要な点です。車両に搭載されているECUを、納入前検査(PDI)、受け入れ港、あるいはディーラーで効率的にアップデートすることができれば、その車両を完全な状態にして新しいオーナーに届けることができます。これは、ソフトウェア・アップデートが頻繁に行われる可能性のあるライフサイクル初期のモデルにとっては、特に重要なことです。

SOTAに関わるその他の機会としては、OEMがコンスーマのために、車両の付加機能のロックを一時的または恒久的に解除できる能力を作り出そうとする場合が挙げられます。その一例としてインフォテイメント・システムを考えてみます。OEMは、将来、顧客が必要に応じて車載ソフトウェアをアップグレードできるようにする可能性があります。日常の運転には、通勤途中にラジオを聞いたり、携帯電話のハンズフリー通話をしたりするための標準的なオーディオ構成で十分でしょう。長い旅行や休暇の場合は、高精細オーディオやオーディオ処理アルゴリズムをアップグレードして、車内の音響分布を最適化するためのオプションをOEMから提供することができます。SOTAを使用すれば、数分間のトランザクションでこのようなアップグレードを容易に行うことが可能なので、OEMは、収益性の高い新たな収入への可能性を開くことができます。

SOTAに関する考慮事項

OEMが車両へのSOTA実装を検討できるようにするには、どの程度の帯域幅が必要なのか、ノード間での伝送をどのように調整するか、セキュリティが必要かどうかなど、いくつかのシステム特性について検討を行う必要があります。

SOTAソリューションが提供する帯域幅は、標準的なソフトウェア・アップデート・ファイルのサイズや、ネットワークを介してソフトウェア・アップグレードを伝送するために使用できる時間などに照らして考える必要があります。多くのソフトウェア・ダウンロードはデルタ・フォーマットで提供され、変更する必要のあるソフトウェア・コンポーネントだけが含まれていますが、それでもファイル・サイズは数十メガバイトの範囲になります。使用できる帯域幅がキロバイト範囲の場合はソフトウェア・アップデートのダウンロードに数十分もかかることがありますが、サービス設定において現実的な値は数分間ないし数秒間の範囲です。

伝送の調整に関する検討には、ネットワークでの信頼性の高い情報伝送を確保するために必要なプロトコルの各側面、すなわちハンドシェイキング、エラー検出、およびエラー・コレクションが含まれます。ハンドシェイキングは、SOTAノードがリンクを介してデータ伝送のネゴシエーションと確認を行うためのプロセスです。例えば、各ブロックの伝送が正常に完了してから、次のブロックを伝送するようにするといったことです。エラー検出は、SOTAノードがリンクを介して伝送されるデータをモニタし、伝送にエラーが発生した場合にそれを確認するプロセスです。この条件を満たすために、例えば、送信ノードと受信ノードの両方で巡回冗長検査(CRC)値を計算する方法が一般的に使われます。エラー・コレクションは、SOTAノードがエラー状態に対応し、可能であればこれを訂正するプロセスです。エラー・コレクションを実装する手法は複数あります。エラーのあった受信データ・ブロックの再送信を送信ノードに要求し直す方法や、フォワード・エラー・コレクション(FEC)などの方式を使用して破損したデータを修復する方法などです。

SOTAソリューションの提供する帯域幅と伝送調整条件によっては、異なるネットワーク上でデータ伝送と伝送調整を行わなければならないことがあります。通常、オートモーティブECUは負荷の異なる複数の通信インターフェース(A2B、CAN、LIN、CXPI、Ethernet、FlexRayなど)を備えており、これが問題となることはほとんどありません。しかし、可能であれば、データ伝送と伝送調整の両方を同じリンク上で行う方が望ましいのは言うまでもありません。

オートモーティブ・ネットワークにおけるセキュリティ上の弱点がもたらす結果は、エシカル・ハッカーが車載ネットワークの制御を奪ったり、ワイパーやステレオ、場合によってはブレーキなどの機能を操ることによってそのリスクを実証したりすることを通じて、多くの機会に強調されてきました。このような弱点は、自動車に乗る人や道路を利用する人の安全に非常に深刻な影響をもたらすおそれがあります。OEMは、すべての車載ネットワークに適切な認証機能を持たせることによって、正当な権限を持たないノードやユーザからのアクセスを防ぐことができるように、対策を講じる必要があります。

これまでに述べた、既に確立されている多くのオートモーティブ・ネットワークは、例えばCANやイーサネットといったSOTAアーキテクチャでの使用に適しています。近年では、ますます複雑化するオーディオ条件から生じる要求に応えるために、事実上アナログ・デバイセズのA2Bが選択されるようになっています。他のネットワーク接続ソリューションよりもオーディオ帯域幅がはるかに広いという利点を持つA2Bは、データを伝送することも可能であり、ハードウェアを追加することなくオーディオ・ネットワークにSOTA機能を組み込む機会をOEMに提供します。

A2Bの概要

A2Bは高帯域幅の双方向デジタルバスで、もともとは、オートモーティブ・アプリケーションにおいて新たに浮上してきたオーディオ配信に関する課題を解決するために考案されたものです。既存のオートモーティブ・オーディオ・アーキテクチャは、通常、ヘッド・ユニット、アンプ、スピーカ、マイクロフォンなどの間で複数のポイントtoポイント・アナログ接続を使用します。A2Bは、ケーブル重量、ケーブルのコスト、配線上の問題点、複数接続における信頼性上の懸念など、ポイントtoポイント・アナログ接続に固有の様々な課題を解決します。A2Bは、シールドなしツイスト・ペア(UTP)ケーブルとコネクタのインフラストラクチャを使用する分散型マルチノード・オーディオ・システムにおいて、完全同期型オーディオ・データ(I2S/TDM/PDM)と制御データ(I2C/SPI)の伝送を容易にします。

A2B Logo

A2Bバスでは、アップストリームとダウンストリームの両方向で最大32チャンネルのオーディオがサポートされており、合計帯域幅は50Mbpsです。A2Bの確定的遅延は50µs未満で、アクティブ・ノイズ・キャンセレーション(ANC)、ロード・ノイズ・キャンセレーション(RNC)、アコースティック・エコー・キャンセレーションおよびノイズ・リダクション(AEC-NR)、ビームフォーミング(BF)など、遅延に敏感なソリューションにとって極めて魅力的なソリューションとなっています。

A2Bは、ポイントtoポイント、デイジーチェーン、ブランチといった複数の異なるトポロジをサポートしており、ヘッド・ユニットとマイクロフォンを備えたエントリーレベルのインフォテイメント・システムから、複数のマイクロフォン、スピーカ、加速度センサーと組み合わせされたECUを備えるRNCなどのより複雑なオーディオ・システムにいたるまで、広範なオートモーティブ・アプリケーションに適したものとなっています。

A2Bネットワークは、メイン・ノードと最大16個のサブノードで構成され、ノード間の最大ケーブル長は15m、メイン・ノードから最後のサブノードまでの最大ケーブル長は80m(ブランチを含む)です。メイン・ノードにはホスト・プロセッサに接続されたA2Bトランシーバーが組み込まれており、A2Bオーディオ・バスを介して、オーディオ、制御データ、およびI2C/SPIデータを送ることができます。サブノードは、重要な処理を行う複雑なパワー・アンプから簡単なマイクロフォン・ノードまで、その複雑さは様々ですが、マイクロフォン、デジタル・シグナル・プロセッサ(DSP)、スピーカ、センサー(例えば加速度センサー)、あるいはクラスDアンプなど、広範な周辺機器とのインターフェースとなるA2Bトランシーバーが組み込まれています。

メイン・ノードとサブノードのトランシーバー・デバイスは、時分割多重(TDM)やパルス密度変調(PDM)によるマイクロフォン入力など、様々な付加価値機能をサポートしています。廉価版のA2Bトランシーバーも存在し、これらはエンドポイント・サブノード・トランシーバー(TDM非対応)や最適化メイン・ノード・トランシーバー(ケーブル長とサブノード数に制約)など、最適化された機能セットを備えています。

ローカル電源を使用するA2Bノードのサポートに加え、A2Bはバス電源を供給して、電源付きリモート・チューナーや、クラスD対応のヘッドレスト・スピーカといった革新的オーディオ機能など、高度なオーディオ・システム・アーキテクチャの実現を容易にします。最新世代のA2Bトランシーバー(AD243x)は、標準バス電力モード(最大2.7W)や高電力モード(最大50W)への対応が可能です。

最初から車載用リンクとして設計されたA2Bは、いくつかの特別な設計上の考慮事項(例えば設定変更可能な出力電力レベル)をトランシーバーに取り入れることでクラス最先端のEMI/EMC性能を実現しており、自動車産業のティア・ワン・サプライヤとOEMが通常経験するEMC上の課題を緩和します。A2Bには、例えばCISPR 25クラス5(エミッション)、ISO 11452-2/ISO 11452-4/ISO 11452-9、ISO 7637-3(電磁耐性)、ISO 10605(ESD)など、あらゆる自動車用EMCテストについて包括的なテストが実施されています。

A2Bによるデータ伝送

オーディオ伝送のサポートに加えて、A2Bは、バスを介してその他の形態のデータを伝送する複数のメカニズムを助ける役割も果たします。バス経由でオーディオとデータ両方の伝送を可能にするA2Bの基本構成要素の1つがスーパーフレームで、これは複数のダウンストリームおよびアップストリーム同期データ・スロット、同期制御フレーム、および同期応答フレームから構成されます。同期データ・スロットはオーディオ・アプリケーションではI2SデータとTDMデータを伝送しますが、SOTAアプリケーションの要求を満たすために他のタイプのデータを伝送するために使用することもできます。

メイン・ノードは、同期制御フレームの後に同期(オーディオ)データと非同期(I2C/SPI)データを追加して、スーパーフレームの伝送を開始します。各サブノードはダウンストリーム・データの一部を使用または消費したり、他のダウンストリーム・ノード用のデータを追加したりすることができます。バス上の最後のサブノードはスーパーフレームのアップストリーム部分を作成し、各ノードは同期応答フレームの後に新たな同期データを追加します。各ノードは、アップストリーム・データを使用したり消費したりできます。 

図2 スーパーフレームの構造

図2 スーパーフレームの構造

いくつかの世代のA2Bトランシーバーがサポートしているもう1つのデータ伝送メカニズムが、メールボックスです。メールボックスは、メイン・ノードとサブノードがネットワーク上でI2Cメッセージを送るために使用でき、メイン・ノードからサブノードへとサブノードからメイン・ノードへの両方向に使われます。メールボックスは通常、メイン・ノード(例えばヘッドユニット)のホストとサブノード(例えばアンプ)のプロセッサ間でハンドシェイキングを確立するために使われます。

ホスト・プロセッサは、A2Bバスを介し、A2Bサブノード・トランシーバーのメールボックス・レジスタに必要なデータをロードすることによって、サブノードのプロセッサとの通信を開始できます。サブノードのA2Bトランシーバーは、I2Cメッセージが存在することを、割込みピン経由でサブノードのプロセッサに通知します。サブノードのプロセッサは、A2BトランシーバーからI2Cを介して、このメッセージを直接読み出すことができます。サブノードのプロセッサは、伝送に必要なデータをサブノード・トランシーバーのメールボックスI2Cレジスタにロードすることによって、メイン・ノードのホストと通信を開始できます。メイン・ノードのA2Bトランシーバーは、サブノード・トランシーバーにI2Cメッセージが存在することを、割込みピン経由でホストに通知します。これを受けてホストは、A2Bバスを介し、サブノード・トランシーバーのメールボックス・レジスタのデータを読み出すことができます。

最新世代のA2Bトランシーバー・ファミリー(AD243x)で導入された第3の伝送メカニズムが、A2Bスーパーフレームの同期スロットを使うSPIデータ長距離伝送です。A2BトランシーバーのSPIインターフェースは、様々なアプリケーションに利用できます。例えば、A2Bトランシーバーを最大10MHzまでのSPIクロック・レートに設定する、サブノード・トランシーバー内のレジスタとステータス情報へのダイレクト・アクセスを実現する、サブノードのSPI対応周辺機器と通信する、メイン・ノードの関与なしでサブノード間におけるSPI同士間の通信を容易にするといった用途です。前世代のA2BトランシーバーにはSPIインターフェースがありませんが、スーパーフレームを透過的に通過させることができ、ネットワーク内の他のノードにSPIデータをアップストリームまたはダウンストリームする機能を備えています。

A2Bリファレンス・ソフトウェア

A2Bでは、ネットワークのあらゆる場所で処理条件が最小限に抑えられているため、ホスト・コントローラがネットワーク全体の完全な初期化をリモートで行う余地があります。ネットワークの設定と、設定後のネットワークの利用に対応するために(例えばイベント/割込み駆動やレジスタ・ポーリング)、アナログ・デバイセズは、ISO/IEC 15504(自動車用SPICE)の基準を満たした包括的なソフトウェア・パッケージを提供しています。このソフトウェアには、Embedded C、Linux®、Android、およびQNX対応のものを含めて複数のバリエーションがあります。これは、製品市場投入までの時間を短縮し、トランシーバー構成に関する最良事例への適合性を確保するためです。

A2Bの基本的動作をサポートするために提供されるソフトウェアに加えて、A2Bを介したデータ伝送などの機能を利用する助けとなる、オプションのソフトウェア・パッケージを使用することもできます。図3に概要を示すように、以上に述べたA2B機能を利用するための各種ソフトウェア・パッケージが用意されています。A2B通信チャンネル・ソフトウェア・アドオンは、A2Bメールボックスを使用して、ネットワーク上のノード間で情報を伝送します。A2Bデータ・パイプ・ソフトウェア・アドオンは、A2B同期スロットを利用して、ネットワーク上のノード間で情報を伝送します。A2Bデータ・トンネル・ソフトウェアは、A2B SPI遠距離データ伝送を利用して、ネットワーク上のノード間で情報を伝達します。

図3 データ伝送に関するA<sup>2</sup>Bのハードウェア機能とソフトウェア機能の相関関係

図3 データ伝送に関するA2Bのハードウェア機能とソフトウェア機能の相関関係

A2Bメールボックス機能と通信チャンネル・ソフトウェア・アドオンを組み合わせると、最大15kbpsのデータ・スループットが得られます。メールボックス機能によって得られるスループットは、診断などのアプリケーションには有効ですが、SOTAのように広い帯域幅を必要とするアプリケーションには不十分です。

A2B同期スロットとデータ・パイプ・ソフトウェア・アドオンを組み合わせると、1Mbps以上のデータ・スループットが得られます。これはSOTAアプリケーションにとって魅力的な通信速度を実現し、例えば20Mbのファイルを20秒で伝送することができます。SPI遠距離データ伝送機能とA2Bデータ・トンネル・ソフトウェア・アドオンを組み合わせると、16Mbps以上のデータ・スループットを実現できます。これはA2Bバスで最も速いデータ通信速度の実現を可能にし、例えば100Mbのファイルは7秒未満で伝送できます。

A2Bツール

A2Bは、業界で認められたアナログ・デバイセズのアルゴリズムおよびネットワーク設計ツールである、SigmaStudio®でもサポートされています。SigmaStudioは、A2Bデザイン・イン・プロセスのあらゆる側面に対応しています。例えば、A2Bノードや補助デバイスのドラッグ・アンド・ドロップによるネットワーク設計、ノードの構成、ビット・エラー・レートの分析、帯域幅計算、消費電力計算などです。SigmaStudioは、提供されたデータを組み合わせて、ユーザのアプリケーション・ソフトウェアへ組み込むための.cファイルや.hファイルを生成します。

テスト機器はあらゆるオートモーティブ技術にとって重要なエコシステム要素であり、A2Bも例外ではありません。アナログ・デバイセズは、既にA2B用のアナライザやモニタを提供している他の信頼できるテスト機器ベンダーに、AD243x製品ファミリの持つすべての機能に対応するために開発されたフル機能のA2Bバス・アナライザを仲間に入れてもらう予定です。

A2Bアナライザは、A2Bネットワークのメイン・ノードまたはサブノードをエミュレートできます。これは、A2Bネットワークの設計とプロトタイプの助けとなります。A2BモニタはA2Bネットワーク上のパッシブ・モニタリング・ノードとして機能し、オーディオの入力と出力をサポートしながら、ノードを通過するA2Bのオーディオとデータを監視します。これらのツールは、製品市場投入時間の短縮と、デザイン・インの複雑さの緩和を支援します。また、A2Bデザイン・インのすべての段階に生じるあらゆる問題のデバッグと調査の速度を向上させます。

A2Bに関しては、A2B設計を市場に投入した実績を持つ複数のサードパーティ設計サービス・パートナーが存在します。これらのパートナーは、既成のハードウェア・モジュールから特注ハードウェア設計およびソフトウェア設計サポートまで、幅広いサービスを提供しています。

オートモーティブ・アプリケーションに推奨されるAD243xファミリの製品は4種類あります。その概要を表1に示します。

表1. AD243xファミリのA2Bデバイス
A2Bデバイス AD2435W AD2433W AD2432W AD2431W
トランシーバーの概要 メイン/サブノード 最適化メイン/サブノード サブノード 最適化エンドポイント・サブノード
メイン・ノード対応 対応 対応 非対応 非対応
機能TRXブロック A + B A + B A + B Aのみ
I2S/TDMのサポート あり あり なし なし
PDMマイクロフォン入力 4 mics 4 mics 4 mics 4 mics
対応サブノード数 最大16
最大16
A2Bバス電力 高(≤ 50W) 標準(≤ 2.7W) 高(≤ 50W) 高(≤ 50W)
公称バス電圧 7V~24V 4V~9V 7V~24V 7V~24V
SPI長距離伝送 あり あり なし なし

A2Bオーディオ・バスは、アナログ・デバイセズが提供する一連の製品評価用ボードを通じてサポートされています。これらのボードは様々なA2Bトランシーバー製品をカバーしており、広範なサードパーティ設計サービスから提供されるその他複数のA2Bボードによって補完されています。

図4 A<sup>2</sup>B評価システムの例

図4 A2B評価システムの例

表2. A2B評価用ボード
A2B評価用ボード 概要
EVAL-AD2435WA3LZ AD243x高電力メイン・ノード評価用ボード、H-DACコネクタ付き
EVAL-AD2435WJ3LZ AD243x高電力バス電源サブノード評価用フル機能ボード、H-DACコネクタ使用
EVAL-AD2435WK3LZ AD243x高電力バス電源サブノード評価用小型ボード、H-DACコネクタ使用
EVAL-AD2433WA1BZ AD243x標準電力メイン・ノード評価用ボード、DuraClikコネクタ使用
EVAL-AD2433WB1BZ AD243x標準電力バス電源評価用ボード、DuraClikコネクタ使用

まとめ

A2Bは、オートモーティブ市場におけるオーディオ・ネットワーキング用の現実的な選択肢として広く認められています。システムに必要とされるものがオーディオ配信なのか、ロード・ノイズ・キャンセレーションやノイズ・リダクションなどの音響機能なのかに関わらず、低遅延や優れたEMC性能といったA2Bが提供する多くの利点は広く知られ、理解されています。A2Bポートフォリオは同じネットワーク上でオーディオ以外のデータを伝送することもでき、オーディオ・ネットワーク上でSOTAを容易かつ効率的にサポートする能力を含めて、いくつかの新しいオプションをシステム設計者は利用できます。

A2B技術の詳細、A2B関連資料、A2Bアプリケーションに関する情報については、analog.com/a2bを参照してください。また、アナログ・デバイセズが提供するA2Bソフトウェアについては、analog.com/jp/design-center/evaluation-hardware-and-software/software/a2b-software.htmlを参照してください。

著者について

Joe Triggs
アナログ・デバイセズのオートモーティブ・ビジネス・ユニットのオートモーティブ・コネクティビティおよびセンシング(ACS)グループでアプリケーション・マネージャを務める。ACSグループは、C2B、A2B、および、ハンズオン検知やTime of Flightといったアナログ・デバイセズのキャビン・センシング技術をサポートしています。2002年ユニバーシティ・カレッジ・コークで1つめの学位(工学の学士号...
Jagannath Rotti
Jagannath Rottiは、アナログ・デバイセズのソフトウェア・リードです。13年間にわたり車載ソフトウェアに携わってきました。入社前は、Robert BoschとAutolivでそれぞれパワートレインと安全性に関する業務に従事していました。アナログ・デバイセズでは、車載ソフトウェア・チームで主にキャビン・エレクトロニクス全般と車載オーディオ・バスに取り組んでいます。関心のある分野は、車載ネットワーク、ネットワークにおけるセキュリティ...
Karthik Radhakrishna
アナログ・デバイセズのソフトウェア・アプリケーション・エンジニア。2011年にアナログ・デバイセズ入社。様々なソフトウェア開発プログラムに参画後アイルランドへ異動し、新たにワイヤレス・バッテリ管理システム(wBMS)を担当。オートモーティブ・インフォテイメント・システムと、ADI SHARC®プロセッサ用オーディオ・フレームワークなどの処理プログラムの経験を有する。最近では、アナログ・デバイセズのオートモーティブ・オー...
Danny Ko
Danny Koは、アナログ・デバイセズのアプリケーション・エンジニアです。韓国 ソウルを拠点として車載オーディオ技術/新技術の開発に携わっています。2004年の入社後、DSPを担当するFAEとして3年間、Samsung ElectronicsやLG Electronicsなど、多様な分野の顧客をサポートしてきました。2007年に車載分野を担当するようになり、2010年からは車載システム・アプリケーション・エンジニアとして車載部門に所属して...

最新メディア 21

Subtitle
さらに詳しく
myAnalogに追加

myAnalog のリソース セクション、既存のプロジェクト、または新しいプロジェクトに記事を追加します。

新規プロジェクトを作成