2023-01-11 :-(
_ 日誌
飯。カレー。
86. 技術広報 w/ hsbt | fukabori.fm を聞く。技術広報の話題。先日弊社でも話題があったようなやつ。世間的には「技術広報」と命名されているらしいのでこの名前を使おう。結局 採用が目的となってしまうわけではあるけど。
ブランドが作れればその会社のイメージが世間に浸透するけど、よくも悪くも浸透する。いいイメージが浸透すればいいけど、悪いイメージが浸透するとよろしくないので難しい。「○○の会社の■■サービスで痛い目にあったので○○会社のサービスはもう使わない」みたいなことになる。
どの会社も給料面は雲泥の差が出るわけではないので、給料以外でアピールしないといけない。
_ DUOS:車載ECU統合向けRTOSフレームワーク
車載制御システムに搭載される電子制御ユニット(ECU) の数が増えているので如何にして減らすか。そのために DUOS というフレームワークを提案した。
ECU 間はネットワーク(ワイヤーハーネス) で接続されて通信する ( いまさら聞けない 車載ネットワーク入門：カーエレクトロニクス技術解説（1/3 ページ） - MONOist ) ECU の数が増えるとそれだけワイヤーハーネスの数も増え、結局ハードウェアが増え、コストが高くなる。
コストを抑えるために ECU を統合し、数を減らしたい。ECU を統合するフレームワークを検討する。そのためのフレームワークとして DUOS を作った。
一般的に ECU 1 つにつき 1 つのアプリケーションが実装されている。 ECU には RTOS が実装され、その上でアプリケーション実装されている。このように 2 つ以上のアプリケーションつまり 2 つ以上の ECU が実装されているので、これを 1 つの ECU に統合する。各 ECU で動作する RTOS はバラバラであり、アプリケーションが利用する API も RTOS ごとにバラバラである。DUOS では複数の RTOS の API を実装することでアプリケーションを移植する手間を減らす。API が変更されればアプリケーションもそれにあわせて変更しなければならないが、ものすごい膨大な変更量になるので変更は無いに越したことは無い。また実装を変更してしまえば当然動作確認もやり直さなければならないので、実装と確認のインパクトを減らすためにも変更は無い方が良い。
DUOS では API の差異を吸収するために抽象化レイヤーを設ける。レイヤーが増えればそのレイヤー間のやりとりのためにオーバーヘッドが生じる。このオーバーヘッドが許容範囲内かどうかが問題である。
今回は 2 つのアプリケーションを統合し実行時間を計測した。その結果オーバーヘッドは生じるが、許容範囲内であろう。
