検索結果

📝 はじめに このページでは、ISO 26262（機能安全）、ISO/SAE 21434（サイバーセキュリティ） と A-SPICE が、 それぞれ何を担当し、何を担当しないのか を構造的に整理する。 規格同士を横並びで比較することが目的ではない。 なぜA-SPICEが「背後」にいて、他規格を支える位置づけになるのか── その理由を理解することが主眼である。 🌍 背景・前提：なぜ規格が増え続けるのか 自動車ソフトウェアは、もはや単なる制御プログラムではない。 機能安全（ISO 26262） サイバーセキュリティ...

📝 はじめに このページでは、A-SPICEを中心（背骨）に据えて、複数規格をどう統合的に設計・運用するかを扱う。 ISO 26262、ISO/SAE 21434、将来のAI・OTA・法規対応── 規格が増えること自体は避けられない。 問題は、それらをどう束ねなければ組織が破綻するかにある。 ここでは、 なぜA-SPICEを「軸」にしないと実務が回らなくなるのか その構造的理由を明確にする。 🌍 背景・前提：規格が増えるほど現場は疲弊する 複数規格を導入した組織で、よく見られる状態がある。 規格ごとに担当部署が...

🧭 はじめに このページでは、A-SPICEにおける プロセス参照モデル（PRM：Process Reference Model） の位置づけと思想を説明する。 PRMはしばしば 「A-SPICEに書いてある標準プロセス」 「この通りにやらなければならない手順書」 のように誤解されがちである。 しかし実際のPRMは、 やり方（How）を定義するものではなく、達成すべき状態（Why / What）を定義する枠組み である。 🌍 背景・前提 📐 なぜ「プロセス」を定義するのか A-SPICEは、個人や一時的な成功では...

🚗 A-SPICE（Automotive SPICE）概要 総論（思想と全体像） 🧭 A-SPICEは何を保証し、何を保証しないのか 🧭 なぜ自動車ソフトの属人化が許されないのか 🧭 V字モデルとA-SPICEの関係を構造で理解する Capability Level（能力レベル） 📊 Capability Levelとは何か（成熟度ではない） 📊 CL1 / CL2 / CL3 の本当の違い 📊 CL2が一番難しい理由 プロセス横断構造 🧱 A-SPICEのプロセスカテゴリ分解の思想 🧱 プロセス間イ...

🧭 はじめに ISO 26262は、自動車に搭載される電気・電子（E/E）システムの機能安全を確保するための国際規格です。 本記事では、ISO 26262が何を目的とし、どのような考え方・構造で成り立っているのかを俯瞰的に整理します。 詳細な手順や成果物よりも、まず「全体像（Why / What）」を理解することを目的とします。 📘 ISO 26262とは何か 🚘 規格の位置づけ ISO 26262は、道路車両（主に乗用車）を対象とした機能安全規格です。 航空（DO-178C）や産業機械（IEC 61508）と同...

🧭 はじめに このページでは、BookStackで「本の骨格（章＋WIPページ）」を作るときに、章IDを手で拾ってシェルのリテラルを書き換える運用をやめて、YAML/JSONの入力ファイルだけで「章作成→配下ページ作成」まで自動化するワークフローをまとめる。 狙いは次の3点。 入力はYAML/JSONだけ（＝章IDの調査・貼り付けを廃止） 章・ページの作成を冪等にする（同名があればスキップ） BookStack API仕様（認証・必須項目・フィルタ）に沿って堅牢にする ブラウザのDevToolsでAPIを叩く運...

🧭 はじめに このページでは、Pythonプロジェクトで pytestをVS Code上で快適に使うための実践手順をまとめます。 対象は「忘れた頃に読み返して、すぐ同じ環境を再現したい」用途です。 単にpytestの使い方を説明するのではなく、 どこにテストを置くべきか どう命名すべきか VS Codeでどう実行・デバッグするか tmp_path の中身をどう確認するか 通常実行と -s（print表示）をどう切り替えるか まで含めて「運用の型」を作ります。 このページのゴールは、「pytestが動く」ではなく...

🧭 はじめに このページでは、pytestで頻出する「デコレータ（decorator）」を、実務で迷わず使える粒度で整理します。 特に、 テストケースが増えて重複がつらい 「条件付きでskipしたい」 「失敗しても良いテストを管理したい」 「テストをカテゴリ分けしたい」 fixtureをどのスコープで使うべきか覚えてない みたいな場面で、忘れても復帰できることを狙います。 結論：pytestのデコレータは「冗長なテストを短くする」ための道具で、正しく使うとテストの可読性と保守性が上がります。 🧩 pytest...

1. 目的 BookStack において、本・章・ページの骨格（章および WIP ページ）を 手作業を排除して一括生成するための Python ツールを作成する。 本ツールは、一度きり使う YAML 定義を入力として、 既存構造を壊さず、安全側（新規作成のみ・既存はスキップ）で動作することを目的とする。 2. 対象スコープ 2.1 対象とする操作 ページの 新規作成 章の 新規作成（存在しない場合のみ） 2.2 対象外とする操作 既存ページ・章の更新 既存ページ・章の削除 YAML と BookStack ...

1. 目的 この YAML は、指定した Book（book_id） に対して以下を上から順に生成するための入力定義である。 Book 直下ページ（pages） 章（chapters）（存在しなければ作成） 章配下ページ（chapters[].pages） 既存の同名ページは SKIP（作らない）。既存の同名章は再利用する。 2. スキーマ（仕様） 2.1 トップレベル キー 型 必須 説明 book_id int 必須 BookStack の book id（名前ではなく ID） wip_...

1. 入力仕様の確定（YAML → ドメイン） YAML スキーマの確定（キー、型、必須/任意） 処理順が意味を持つことの明文化 不正入力の扱い（エラーにする条件）の洗い出し ドメインデータクラス定義 Book 単位 Chapter 単位 ドメインレベルでのバリデーション仕様決定 必須チェック 重複チェック 型チェック 2. 同一性判定ルールの具体化 Book 直下ページの同一性判定方法 Chapter の同一性判定方法 Chapter 配下ページの同一性判定方法 SKIP 条件...

1. 入力全体の位置づけ 入力は 一度きり使う YAML 定義 YAML に書かれた 記載順＝処理順 既存構造は破壊せず、新規作成のみ 既存要素が存在する場合は SKIP YAML は BookStack の状態と同期しない（使い捨て） 2. トップレベルスキーマ book_id: int wip_markdown: string pages: list[string] # optional chapters: list[chapter] # optional 2.1 トップレベル項目定...

1. 設計方針 入力1ファイル＝1 Book（book_id を必須） 記載順は意味を持つため、list の順序は保持する 既存更新・削除はしない（SKIP 判定は後段のユースケースで行う） データクラスは YAML スキーマの写像に徹し、BookStack API 概念（id 等）は持たない None を持ち込まず、後段ロジックの分岐を減らすため 空リストに正規化する 文字列は前後 trim（strip）してから保持する（本仕様で固定） 2. データクラス一覧 2.1 BookInput（入力全体） ...

🧭 はじめに ISO 21434 は、自動車（車載ECU・車載ネットワーク・ソフトウェア・クラウド連携など）を対象にした サイバーセキュリティの国際規格です。 一言でいうと、「車がネットワークにつながることによって発生する脅威（攻撃）に対して、開発から運用まで一貫して安全性を確保するための“やり方（プロセス）”」を定めます。 ISO 26262（機能安全）が「故障による危険」を扱うのに対し、ISO 21434 は「攻撃による危険」を扱うのが中心です。 ISO 21434 は「セキュリティ機能の実装カタログ」ではなく...