2024-12-03-OSPO-EG Japan Local Call

Owned by Masanori Itoh
Last updated: Dec 10, 2024
3 min read

Date/Time

Dec. 3, 2024, 1, 3:00pm(JST) via Zoom

Attendees

  • Endo, Itoh, Yamashita (Toyota)

  • Ishii (Panasonic)

  • Nagayama (Nissan)

  • Yamaguchi, Yamada, Nakamura (AISIN)

  • Kurihara, Tomita, Ishida, Takagi(DENSO)

  • (absent) Tsubouchi (Honda)

Agenda

  • Recap of the kick-off and 2nd OSPO-EG global calls.

  • Free Discussion

Discussion Materials

  • Used slide decks of the kick-off/2nd calls

Minutes

  • Communication

    • Some companies have restriction using Slack and/or Discord. Regarding Confluence, special care for getting update notifications needed. The most practical communication method would be Mailing List.

    • Maybe it’s better to ask Walt to create local community mailing list (group), agl-local-japan or agl-japan where Japanese messages are accepted.

    • Regarding 40min restriction of a free Zoom account, Walt kindly mentioned it’s possible to setup LFX Zoom session after the meeting. We will consult with Walt later because the regular time slot is still under discussion (because key persons are always busy!).

  • Documentation and Functional Safety

    • As examples of OSS problems, it was pointed out (again) lack of documentation and Functional Safety.

    • There was a question if Functional Safety is within the scope of OSPO-EG activity. The consensus at the meeting was like :

      • Working on Functional Safety itself is out-of-scope of OSPO-EG, but the followings are in-scope.

        • Collecting use cases/requirements of Functional Safety regarding OSS

        • Sharing them with appropriate organization(s) like ELISA and work together with them

    • At ELISA, automotive team is focusing on Linux kernel not covering generic OSS components. But, Functional Safety is required in also other industries and we, automotive industry, have our own specific Functional Safety requirements. It’s an idea that we compile and input them to ELISA from OSPO-EG.

    • Regarding documentation, there are several layers of problems. It’s necessary to analyze what kind documentations are required from the first place.

      • For example, an attendee has experience to be asked “Please write specification/design document of an OSS“. He thought carrying out reverse engineering of the OSS at that time.

      • One possible work item could be creating a list of documents necessary when we use OSSes for Functional Safety area.

        • Maybe it’s possible to hire a contractor to work on this within AGL budget. We can carry out community review of the deliverables.

  • Culture of Automotive Industry : Change or No-Change

    • (At least so far) Automotive industry folks do not want to change existing/working things(software),but it’s a premise to change things (e.g. refactoring of even working components) in OSS world. It’s time consuming starting from explaining why we need to change (even working) things (without any problems). We need to persuade them to convince that nowadays software is like that (to be changed continuously). It’s great if we can have advices how to change the way they think.

    • The wording “upstream first“ tends to be misunderstood in legacy companies. Better to have a presentation deck from this aspect.

      • Better to explain explicitly using documentations/presentations.

    • Maybe the outcome could be something like “SBOM Telco spec.”?

      • The work should belong to OpenChain. OSPO-EG can be something like a concierge.

  • Support for OSPO launch process

    • It’s of course within the scope of AGL OSPO-EG.

    • In case of a member company, they don’t have knowhow of launching a new organization working on OSS. So, it’s greatly appreciated if they can have a place that they can consult with about experiences not only knowledge. It would be great if we can share know-how on operation of an organization/fostering awareness because OSS experienced engineers do not come togather naturally.

    • If number of engineers contributing OSS daily basis (including private activity) increased, it would improve base skills like writing codes. It’s great if it improves development activity at work too.

    • It would be difficult that company side support everything regarding contribution. Rather, it could belong to community side. From a view point of companies, it would be good if they can support engineers by establishing rules to support (not restrict) contribution. Launching an OSPO is one mean.

    • In the executive presentation deck, it’s important to write down a story. For example, without OSS our business cannot survive/sustain.

  • New AGL Reference Development Board

    • It’s getting a critical issue that AGL developers cannot access to newer generation development board because of NDA with SoC vendors. Need to discuss the issue with SoC vendors.

Minutes in Japanese (original)

  • 初回と第二回のふりかえり

  • かるい自己紹介

  • 議論

  • OSSにネガティブな理由として、ドキュメントや機能安全の件がある。特に自動運転系のセンサとかactuatorで使っていると困る。こういう話はスコープか？

  • Functional Safetyそのものを議論することはないが、ユースケースやニーズをまとめてELISAなどのしかるべき団体に送るのはスコープ。

  • ELISAはLinux kernelの話が中心で、OSS一般の扱いという話にならない。LinuxをASIL-Bに使うためにどうすればよいか、ELISAで話をはじめている。

  • ELISAはautomotiveチームがLinux kernelにfocusしているということだと思うが、機能安全が必要なのは自動車だけではなく、自動車ならではの特異性もあるという声がある。それをAGLでまとめるのはあるだろう。話の進め方として、Linux kernelで蓄積した機能安全の知見を他に展開する云々という進め方もある。

  • 不安(やニーズ)をとりまとめて、ELISA等適切なコミュニティにインプットするのはあり。

  • ELISAでは、ユースケースの１つが自動車。ユースケースを分析することになるが、それをOSPOがとりまとめてインプットするという方向。

  • 問題は何段階か存在する。そもそもOSSにおいてどういうドキュメントをかけばよいのか分析が必要。

  • OSSの仕様書がないか？と聞かれることもある。リバースするとか...

  • OSSをFunctional Safetyが求められる領域で使うにあたって必要なドキュメント(の、まず一覧？)を作るとか。(AGLの)開発費用の中に入れてやるとか。このコミュニティでレビューするとか。

  • OSPOのコントリのやりかたの１つ

  • TECHPLAYのTMC村田さんの話にもあったが、自動車業界は変えたがらない vs OSSは変えるのが前提。なぜ変えたがらないのか、そこから議論が始まってしまう。ソフトってそういうものと伝える必要がある。

  • 「変えると品質にインパクトあるじゃん」と言われる。変える <->品質のトレードオフの前提の人がいるので、意識変革にアドバイスがあるとよい

  • OSSもその１つの文脈

  • upstream firstって誤解を受けやすいので説明を作れるとよい

  • こういう点は、さらっとながさずにちゃんと資料で説明したほうがよいということ

  • SBOM Telco Spec.みたいなやつのAutomotive Spec.とか出てくるのでは？

  • それはOSPO-EGではなく、OpenChainでやればよいのでは。(今やってないだけ)

  • OSPO-EGがそういう話の駆け込み寺になるとドキュメントにかけばよいということ

  • この会の趣旨として「各社でOSPOがたちがっている状態」を作ることを支援する活動があるとうれしい。ある会社の場合は、組織立ち上げのノウハウがないので、実践するにあたって知識だけでなく経験が重要…なので相談できる場があるとうれしい。コントリするエンジニアは勝手にあつまるわけではなく、マインド醸成なりの方法を共有、運営のノウハウの共有等ができるとよい

  • 是非やりたい

  • 社内に(privateも含めて)日常的にcontributionしている人が増えると、コードの書き方なり、ベースのスキルもあがってくるだろう。そこから学んで業務の開発に反映できるとよい

  • エンジニアがコントリの仕方を学ぶのを会社が全部支えるのは難しいと思う。支援はありだが。むしろそれはコミュニティでは。会社としては、ルール整備などでコントリできない…という状況を(OSPOを作って)ささえるというのがよい

  • アドベントカレンダーのように、イベント的にやるとか。それがないと事業が成り立たないというようなものだからコントリして支えるとか。ストーリー/プラクティスのドキュメントへの反映。

  • 現場の人が出ていく入り口にする

  • SOCのNDAのせいで、コミュニティの人が開発ボードに触れないのがcriticalになってきている。

  • (OSS/AGLで)次の世代のSOCが決められないということになる

  • SOCベンダを巻き込んだ議論をしないといけない。Flutter等、上物はよいのだが...

  • コミュニケーション

  • Slackは無償プランなので流れてします。Discordはアクセスできない会社もある。Confluenceを掲示板的に使う案もあるが、更新に気づかない。現状はMLが現実的。

  • チャタムハウスルールにするかどうかは今後調整

 

Next Meeting

  • Under discussion

    • Likely bi-weekly