diff --git a/docs/README.md b/docs/README.md
index 884e3586d..777af589c 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -6,19 +6,19 @@
 C2A に関する説明の棲み分けは，次のようになっています．
 
 - C2A のコードとそのコメント
-    - マスター情報
-    - 変数や構造体，関数などの定義などを Doxygen 形式で記述
+  - マスター情報
+  - 変数や構造体，関数などの定義などを Doxygen 形式で記述
 - C2A リファレンス: https://github.com/ut-issl/c2a-reference
-    - C2A のコードから自動生成されるもの (Doxygen)
-    - 変数や構造体の定義，関数の相関図なども閲覧可能
+  - C2A のコードから自動生成されるもの (Doxygen)
+  - 変数や構造体の定義，関数の相関図なども閲覧可能
 - 本ドキュメント
-    - マスター情報はコードとそのコメントなため，それを補足する情報など
-        - C2A 全体の説明
-        - 設計思想
-        - 規則など
-        - 操作方法や設定方法などの手順
-        - などなど
-    - したがって，マスター情報の二重管理を避けるため，本ドキュメントには，変数定義の説明などは記載しないこと！
+  - マスター情報はコードとそのコメントなため，それを補足する情報など
+    - C2A 全体の説明
+    - 設計思想
+    - 規則など
+    - 操作方法や設定方法などの手順
+    - などなど
+  - したがって，マスター情報の二重管理を避けるため，本ドキュメントには，変数定義の説明などは記載しないこと！
 
 以上より，本ドキュメントと合わせてコードを見ることを推奨する．  
 （@ドキュメント記入者: 各ドキュメントから関連コードにリンクが張ってある状態が望ましい．）
@@ -27,25 +27,25 @@ C2A に関する説明の棲み分けは，次のようになっています．
 ## 目次
 
 1. General Information
-    1. [Overview](./general/overview.md)
-    1. [Release](./general/release.md)
-    1. [Coding Rule](./general/coding_rule.md)
-    1. [Coding Acronyms](./general/coding_acronyms.md)
+   1. [Overview](./general/overview.md)
+   1. [Release](./general/release.md)
+   1. [Coding Rule](./general/coding_rule.md)
+   1. [Coding Acronyms](./general/coding_acronyms.md)
 1. Application Layer
-    1. [Overview](./application/overview.md)
-    1. How to add a application
+   1. [Overview](./application/overview.md)
+   1. How to add a application
 1. Core Layer
-    1. Overview
-    1. [Communication](./core/communication.md)
-    1. [Tips](./core/tips.md)
+   1. Overview
+   1. [Communication](./core/communication.md)
+   1. [Tips](./core/tips.md)
 1. Component Driver
-    1. [Overview](./component_driver/overview.md)
-    1. [Communication with Components](./component_driver/communication_with_components.md)
+   1. [Overview](./component_driver/overview.md)
+   1. [Communication with Components](./component_driver/communication_with_components.md)
 1. Development
-    1. [Development Environment](./development/development_environment.md)
-    1. [Tools](./development/tools.md)
+   1. [Development Environment](./development/development_environment.md)
+   1. [Tools](./development/tools.md)
 1. SILS
-    1. [c2a-sils-runtime](./sils/c2a_sils_runtime.md)
-    1. [S2E Integration](./sils/s2e_integration.md)
+   1. [c2a-sils-runtime](./sils/c2a_sils_runtime.md)
+   1. [S2E Integration](./sils/s2e_integration.md)
 1. Tips
-    1. [Parameter Settings](./tips/parameter_settings.md)
+   1. [Parameter Settings](./tips/parameter_settings.md)
diff --git a/docs/application/overview.md b/docs/application/overview.md
index cc4575d37..e13b513f5 100644
--- a/docs/application/overview.md
+++ b/docs/application/overview.md
@@ -2,17 +2,17 @@
 
 ## Application
 - Application とは，以下の4つに分類される．
-    - Core
-    - User Defined
-    - Middleware
-    - Driver Instance
+  - Core
+  - User Defined
+  - Middleware
+  - Driver Instance
 - Application は，以下の要素によって構成される．
-    - Application 実体
-        - 内部状態を保存する AppInfo 構造体
-        - 初期化関数 (initializer)
-        - 実行関数 (executor)
-    - コマンド
-    - テレメトリ
+  - Application 実体
+    - 内部状態を保存する AppInfo 構造体
+    - 初期化関数 (initializer)
+    - 実行関数 (executor)
+  - コマンド
+  - テレメトリ
 
 ## Application実体
 ### 内部状態を保存する AppInfo構造体
@@ -28,8 +28,8 @@
 ## コマンド
 - 処理の最小単位
 - 以下のような処理をする
-    - アプリケーションの一部処理を単独で行う
-    - アプリケーションの内部状態を更新する
+  - アプリケーションの一部処理を単独で行う
+  - アプリケーションの内部状態を更新する
 
 
 ## テレメトリ
diff --git a/docs/component_driver/communication_with_components.md b/docs/component_driver/communication_with_components.md
index 5388ab405..95aa4c6d6 100644
--- a/docs/component_driver/communication_with_components.md
+++ b/docs/component_driver/communication_with_components.md
@@ -51,14 +51,14 @@ https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e
 
 #### 各フィールドの説明
 - Version ID
-    - `0x00`: バージョン不定
-    - `0x01`: Version 1
+  - `0x00`: バージョン不定
+  - `0x01`: Version 1
 - Tlm / Cmd Count
-    - 送信 Packet 毎にインクリメントされていくカウンタ
+  - 送信 Packet 毎にインクリメントされていくカウンタ
 - Tlm / Cmd ID
-    - Packet 種別を表す ID
+  - Packet 種別を表す ID
 - User Data Field
-    - バイト単位で格納されたユーザーデータ
+  - バイト単位で格納されたユーザーデータ
 
 なお，すべてのフィールドのバイトオーダはビッグエンディアンとする．
 
@@ -72,20 +72,20 @@ https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e
 
 #### 各フィールドの説明
 - STX
-    - Frame 先頭識別子
-    - `0xEB 0x90` 固定
+  - Frame 先頭識別子
+  - `0xEB 0x90` 固定
 - Packet Length
-    - Packet Field の長さ
+  - Packet Field の長さ
 - CRC
-    - Packet Field 部分の CRC (Header は含めない)
-    - 使用する CRC の種類は CRC-16/CCITT-FALSE (CRC-16/AUTOSAR, CRC-16/IBM-3740 とも)
-    - `width=16, poly=0x1021, init=0xffff, refin=false, refout=false, xorout=0x0000, check=0x29b1, residue=0x0000`
+  - Packet Field 部分の CRC (Header は含めない)
+  - 使用する CRC の種類は CRC-16/CCITT-FALSE (CRC-16/AUTOSAR, CRC-16/IBM-3740 とも)
+  - `width=16, poly=0x1021, init=0xffff, refin=false, refout=false, xorout=0x0000, check=0x29b1, residue=0x0000`
 - ETX
-    - Frame 終端識別子
-    - `0xC5 0x79` 固定
+  - Frame 終端識別子
+  - `0xC5 0x79` 固定
 - Packet Field
-    - バイト単位で格納された送信 Packet
-    - EB90 Packet や Common Packet などが格納される
+  - バイト単位で格納された送信 Packet
+  - EB90 Packet や Common Packet などが格納される
 
 なお，すべてのフィールドのバイトオーダはビッグエンディアンとする．
 
@@ -95,13 +95,13 @@ https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e
 C2A 間通信によって，以下のような機能が提供される．
 
 - OBC 間の簡易な Driver 実装と自動コード生成
-    - [c2a-code-generator](../../code-generator/) 参照．
-    - [`examples/mobc/src/src_user/Drivers/Aocs`](/examples/mobc/src/src_user/Drivers/Aocs/) などの多くのコードが自動生成される．
+  - [c2a-code-generator](../../code-generator/) 参照．
+  - [`examples/mobc/src/src_user/Drivers/Aocs`](/examples/mobc/src/src_user/Drivers/Aocs/) などの多くのコードが自動生成される．
 - OBC と地上局でネットワークを形成．
-    - 地上局から MOBC をルーターとして， sub OBC へコマンド配送．
-    - sub OBC のテレメトリを MOBC を経由して地上局まで配送．
-    - OBC A から OBC B に対してコマンド発行 / テレメ送信．
-    - 他
+  - 地上局から MOBC をルーターとして， sub OBC へコマンド配送．
+  - sub OBC のテレメトリを MOBC を経由して地上局まで配送．
+  - OBC A から OBC B に対してコマンド発行 / テレメ送信．
+  - 他
 
 C2A 間通信の具体的な実装については，本リポジトリに同封されている User Sample である [`examples/mobc`](/examples/mobc) と [`examples/subobc`](/examples/subobc) での通信（前者が MOBC，後者が AOBC を想定）を参考にされたい．
 具体的なドライバのコードは以下となる．
diff --git a/docs/component_driver/overview.md b/docs/component_driver/overview.md
index 23e888f25..91178a47b 100644
--- a/docs/component_driver/overview.md
+++ b/docs/component_driver/overview.md
@@ -13,8 +13,8 @@ Component Driver とは，各コンポーネントとの通信において， HW
 - UART test: https://github.com/arkedge/c2a-core/blob/develop/examples/mobc/src/src_user/component_driver/etc/uart_test.c
 - GS: https://github.com/arkedge/c2a-core/blob/develop/examples/mobc/src/src_user/component_driver/com/gs.c
 - C2A 間通信:
-    - https://github.com/arkedge/c2a-core/blob/develop/examples/mobc/src/src_user/component_driver/aocs/aobc.c
-    - https://github.com/arkedge/c2a-core/blob/develop/examples/subobc/src/src_user/component_driver/etc/mobc.c
+  - https://github.com/arkedge/c2a-core/blob/develop/examples/mobc/src/src_user/component_driver/aocs/aobc.c
+  - https://github.com/arkedge/c2a-core/blob/develop/examples/subobc/src/src_user/component_driver/etc/mobc.c
 
 が実装されているので，それを参考のこと．  
 `load_init_setting` については下を参照．
@@ -91,7 +91,7 @@ TBW
 - コードの見通しの良さの大幅改良
 - 高速化
 - 複数のフレーム定義（＝ヘッダフッタやフレーム長）に対応するためのStreamの新設
-    - これまでは定期・非定期で２つあったが，これがコードの見通しの良さとバグの温床になっていた
+  - これまでは定期・非定期で２つあったが，これがコードの見通しの良さとバグの温床になっていた
 - varidationの強化
 
 各ドライバの実装方法は，上で述べたように既存コードを参照してほしいが，初期化時にユーザー設定をデフォルト設定で上書きするための `load_init_setting` 関数ポインタを渡す必要がある．  
diff --git a/docs/core/communication.md b/docs/core/communication.md
index 915f7cb85..25a3f71a6 100644
--- a/docs/core/communication.md
+++ b/docs/core/communication.md
@@ -8,15 +8,15 @@
 ## C2A 内部を流れるパケットについて (Common Packet)
 C2A 内部を流れるパケットは以下の 3 つである．
 - `CommonTlmCmdPacket`
-    - CTCP
-    - テレコマを区別しないパケット
-    - CCSDS で規定される Space Packet に相当する
+  - CTCP
+  - テレコマを区別しないパケット
+  - CCSDS で規定される Space Packet に相当する
 - `CommonTlmPacket`
-    - CTP
-    - CTCP のうち，テレメトリパケットに限定したもの
+  - CTP
+  - CTCP のうち，テレメトリパケットに限定したもの
 - `CommonCmdPacket`
-    - CCP
-    - CTCP のうち，コマンドパケットに限定したもの
+  - CCP
+  - CTCP のうち，コマンドパケットに限定したもの
 
 これらのパケットは，抽象化された型であり，その実体はすべてユーザー定義である．  
 C2A 標準として， Space Packet が Core 内で定義されており，基本的にはこれを用いることを想定している．
@@ -40,30 +40,30 @@ https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e
 
 #### 各フィールドの説明
 - Packet Version Number
-    - `0b000` Space Packet 固定
+  - `0b000` Space Packet 固定
 - Packet Identification
-    - Packet Type
-        - `0b0`: Telemetry
-        - `0b1`: Command
-    - Secondary Hreader Flag
-        - `0b0`: Secondary Header Absent
-        - `0b1`: Secondary Header Present
-    - Application Process Identifier (APID)
-        - ユーザー定義
-        - 以下は CCSDS で規定
-            - `0b11111111000` - `0b11111111110`: CCSDS Reserved
-            - `0b11111111111`: Idle Packet
+  - Packet Type
+    - `0b0`: Telemetry
+    - `0b1`: Command
+  - Secondary Hreader Flag
+    - `0b0`: Secondary Header Absent
+    - `0b1`: Secondary Header Present
+  - Application Process Identifier (APID)
+    - ユーザー定義
+    - 以下は CCSDS で規定
+      - `0b11111111000` - `0b11111111110`: CCSDS Reserved
+      - `0b11111111111`: Idle Packet
 - Packet Sequence Control Field
-    - Sequence Flag
-        - `0b00`: Continuation component of higher data structure
-        - `0b01`: First component of higher data structure
-        - `0b10`: Last component of higher data structure
-        - `0b11`: Standalone Packet
-    - Sequence Count
-        - APID ごとにパケットの伝送順番を示すカウンタ
+  - Sequence Flag
+    - `0b00`: Continuation component of higher data structure
+    - `0b01`: First component of higher data structure
+    - `0b10`: Last component of higher data structure
+    - `0b11`: Standalone Packet
+  - Sequence Count
+    - APID ごとにパケットの伝送順番を示すカウンタ
 - Packet Data Length
-    - パケット全長から Primary Header 長を引き，さらに 1 を引いたもの
-    - つまり，これが 0 の時， Secondary Header + User Data Field 長は 1 byte である
+  - パケット全長から Primary Header 長を引き，さらに 1 を引いたもの
+  - つまり，これが 0 の時， Secondary Header + User Data Field 長は 1 byte である
 
 
 ### Secondary Header (Telemetry)
@@ -73,39 +73,39 @@ https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e
 
 #### 各フィールドの説明
 - Secondary Header Version
-    - `0x00`: バージョン不定
-    - `0x01`: Version 1
+  - `0x00`: バージョン不定
+  - `0x01`: Version 1
 - Board Time
-    - テレメトリが生成されたボード (OBC など) の時刻 (TI など)
+  - テレメトリが生成されたボード (OBC など) の時刻 (TI など)
 - Telemetry ID
-    - テレメトリID
-    - APID 内でユニークであればいい
+  - テレメトリID
+  - APID 内でユニークであればいい
 - Global Time
-    - テレメトリが生成された絶対時刻 (unixtime や GPS Time など)
-    - APID ごとに解釈方法（ビットフィールドの使い方）を定義する
-    - `0xFFFFFFFF 0xFFFFFFFF` の場合， パケット中継中に MOBC (地上局とつながる OBC) で，上書き設定される
-        - Global Time を取得できない機器向け
+  - テレメトリが生成された絶対時刻 (unixtime や GPS Time など)
+  - APID ごとに解釈方法（ビットフィールドの使い方）を定義する
+  - `0xFFFFFFFF 0xFFFFFFFF` の場合， パケット中継中に MOBC (地上局とつながる OBC) で，上書き設定される
+    - Global Time を取得できない機器向け
 - On-Board Subnetwork Time （将来拡張）
-    - 各ボードで作られたパケットの時刻を統一的に管理するために，オンボードサブネットワークで共通の時刻体系に基づくテレメトリ生成時刻
-    - `0xFFFFFFFF` の場合， パケット中継中に MOBC (地上局とつながる OBC) で，上書き設定される
-        - On-Board Subnetwork Time を取得できない機器向け
+  - 各ボードで作られたパケットの時刻を統一的に管理するために，オンボードサブネットワークで共通の時刻体系に基づくテレメトリ生成時刻
+  - `0xFFFFFFFF` の場合， パケット中継中に MOBC (地上局とつながる OBC) で，上書き設定される
+    - On-Board Subnetwork Time を取得できない機器向け
 - Destination Flags
-    - テレメトリ配送種別
-    - 同時に複数配送ができるように， flag で管理
-        - ただし，地上局でのパケット保存処理をシンプルにするためなどの理由で，配送の過程でそれぞれのフラグごとにバケットをバラす．つまり，オンボードサブネットワークから地上に送信されるパケットでは， 1 つの flag のみ立っている状態を基本とする．
-    - 今後拡張予定あり
-    - 現時点では以下
-        - `0b00000001`: High Priority Realtime Telemetry (現在の C2A Core では使われてない (Realtime Telemetry として処理されている))
-        - `0b00000010`: Realtime Telemetry
-        - `0b00000100`: Stored Telemetry
-        - `0b00001000`: Replay Telemetry
-        - `0b00010000`: 将来拡張用の確保領域
-        - `0b00100000`: 将来拡張用の確保領域
-        - `0b01000000`: 将来拡張用の確保領域
-        - `0b10000000`: 将来拡張用の確保領域
+  - テレメトリ配送種別
+  - 同時に複数配送ができるように， flag で管理
+    - ただし，地上局でのパケット保存処理をシンプルにするためなどの理由で，配送の過程でそれぞれのフラグごとにバケットをバラす．つまり，オンボードサブネットワークから地上に送信されるパケットでは， 1 つの flag のみ立っている状態を基本とする．
+  - 今後拡張予定あり
+  - 現時点では以下
+    - `0b00000001`: High Priority Realtime Telemetry (現在の C2A Core では使われてない (Realtime Telemetry として処理されている))
+    - `0b00000010`: Realtime Telemetry
+    - `0b00000100`: Stored Telemetry
+    - `0b00001000`: Replay Telemetry
+    - `0b00010000`: 将来拡張用の確保領域
+    - `0b00100000`: 将来拡張用の確保領域
+    - `0b01000000`: 将来拡張用の確保領域
+    - `0b10000000`: 将来拡張用の確保領域
 - Destination Info
-    - 例えば，Stored Telemetry 時には Data Recorder のどのパーティションに配送されるかを規定する
-    - 将来拡張の可能性あり
+  - 例えば，Stored Telemetry 時には Data Recorder のどのパーティションに配送されるかを規定する
+  - 将来拡張の可能性あり
 
 
 ### Secondary Header (Command)
@@ -115,65 +115,65 @@ https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e
 
 #### 各フィールドの説明
 - Secondary Header Version
-    - `0x00`: バージョン不定
-    - `0x01`: Version 1
+  - `0x00`: バージョン不定
+  - `0x01`: Version 1
 - Command Type
-    - 将来拡張用
-    - 現時点では以下
-        - `0x00`: 不定
+  - 将来拡張用
+  - 現時点では以下
+    - `0x00`: 不定
 - Command ID
-    - コマンドID
-    - APID 内でユニークであればいい
+  - コマンドID
+  - APID 内でユニークであればいい
 - Destination Type
-    - `0x0`, `0xe`, `0xf` 以外はユーザー定義
-    - 例えば次のように定義する
-        - `0x0`: 自分宛 (`CCP_DEST_TYPE_TO_ME`)
-        - `0x1` - `0xd` : `CCP_DEST_TYPE_TO_ME`, `CCP_DEST_TYPE_TO_APID` では表現できない宛先
-        - `0xe`: 不明 (`CCP_DEST_TYPE_TO_UNKOWN`)
-        - `0xf`: APID で示す宛先宛 (`CCP_DEST_TYPE_TO_APID`)
-    - ここで言う，宛先はコマンド実行場所ではなく，キューイングされる先のことである（詳細は後述）
+  - `0x0`, `0xe`, `0xf` 以外はユーザー定義
+  - 例えば次のように定義する
+    - `0x0`: 自分宛 (`CCP_DEST_TYPE_TO_ME`)
+    - `0x1` - `0xd` : `CCP_DEST_TYPE_TO_ME`, `CCP_DEST_TYPE_TO_APID` では表現できない宛先
+    - `0xe`: 不明 (`CCP_DEST_TYPE_TO_UNKOWN`)
+    - `0xf`: APID で示す宛先宛 (`CCP_DEST_TYPE_TO_APID`)
+  - ここで言う，宛先はコマンド実行場所ではなく，キューイングされる先のことである（詳細は後述）
 - Execution Type
-    - 現時点では以下（将来拡張予定あり）
-        - `0x0`: Ground Station Command
-        - `0x1`: Timeline Command (TL0)
-        - `0x2`: Block Command
-        - `0x3`: Realtime Command
-        - `0x4`: Unixtime Timeline Command (TL0)
-        - `0x5`: Timeline Command (TL1)
-        - `0x6`: Timeline Command (TL2)
-        - `0x7`: 不明
-    - ルーティングについては後述
+  - 現時点では以下（将来拡張予定あり）
+    - `0x0`: Ground Station Command
+    - `0x1`: Timeline Command (TL0)
+    - `0x2`: Block Command
+    - `0x3`: Realtime Command
+    - `0x4`: Unixtime Timeline Command (TL0)
+    - `0x5`: Timeline Command (TL1)
+    - `0x6`: Timeline Command (TL2)
+    - `0x7`: 不明
+  - ルーティングについては後述
 - Time Indicator
-    - TLC や BC における実行時刻を示す TI
+  - TLC や BC における実行時刻を示す TI
 
 #### コマンド配送におけるルーティングについて
 - コマンドの最終的な配送先，つまり実行されるボードは APID によって規定される
-    - https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e9/Examples/mobc/src/src_user/Settings/TlmCmd/Ccsds/apid_define.h#L11-L28
+  - https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e9/Examples/mobc/src/src_user/Settings/TlmCmd/Ccsds/apid_define.h#L11-L28
 - 一方で， BC や TLC などでのキューイングは， Destination Type によって決定される
-    - https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e9/Examples/mobc/src/src_user/Settings/TlmCmd/common_cmd_packet_define.h#L20-L34
+  - https://github.com/arkedge/c2a-core/blob/45d78a05c339c285b5aa0c2fcbf57c1b105137e9/Examples/mobc/src/src_user/Settings/TlmCmd/common_cmd_packet_define.h#L20-L34
 - 具体例（GS と接続される OBC は MOBC とし，AOBC は MOBC にぶら下がってるものとする）
-    - APID: MOBC, Destination Type: TO_ME or TO_APID or MOBC
-        - GSC: GS から MOBC に届き， MOBC で GSC としてエンキューされる．デキューした後， MOBC 内で GSC として実行される．
-        - TLC: GS から MOBC に届き， MOBC で TLC としてエンキューされる．デキューした後， MOBC 内で RTC として実行される．
-        - BC: GS から MOBC に届き， MOBC で BC 登録される．BC 展開した後， TL にエンキューされ，デキューした後， MOBC 内で RTC として実行される．
-    - APID: AOBC, Destination Type: TO_ME or MOBC
-        - GSC: GS から MOBC に届き， MOBC で GSC としてエンキューされる．デキューした後， APID を元に， AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で RTC としてキューイング & 実行される．
-        - TLC: GS から MOBC に届き， MOBC で TLC としてエンキューされる．デキューした後， APID を元に， AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で RTC としてキューイング & 実行される．
-        - BC: GS から MOBC に届き， MOBC で BC 登録される．BC 展開した後， TL にエンキューされ，デキューした後， APID を元に， AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で RTC としてキューイング & 実行される．
-    - APID: AOBC, Destination Type: TO_APID or AOBC
-        - GSC: GS から MOBC に届き， MOBC でエンキューされずに，そのまま AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で GSC としてキューイング & 実行される．
-        - TLC: GS から MOBC に届き， MOBC でエンキューされずに，そのまま AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で TLC としてキューイング & 実行される．
-        - BC: GS から MOBC に届き， MOBC で BC 登録されずに，そのまま AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で BC として登録 & 実行される．
+  - APID: MOBC, Destination Type: TO_ME or TO_APID or MOBC
+    - GSC: GS から MOBC に届き， MOBC で GSC としてエンキューされる．デキューした後， MOBC 内で GSC として実行される．
+    - TLC: GS から MOBC に届き， MOBC で TLC としてエンキューされる．デキューした後， MOBC 内で RTC として実行される．
+    - BC: GS から MOBC に届き， MOBC で BC 登録される．BC 展開した後， TL にエンキューされ，デキューした後， MOBC 内で RTC として実行される．
+  - APID: AOBC, Destination Type: TO_ME or MOBC
+    - GSC: GS から MOBC に届き， MOBC で GSC としてエンキューされる．デキューした後， APID を元に， AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で RTC としてキューイング & 実行される．
+    - TLC: GS から MOBC に届き， MOBC で TLC としてエンキューされる．デキューした後， APID を元に， AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で RTC としてキューイング & 実行される．
+    - BC: GS から MOBC に届き， MOBC で BC 登録される．BC 展開した後， TL にエンキューされ，デキューした後， APID を元に， AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で RTC としてキューイング & 実行される．
+  - APID: AOBC, Destination Type: TO_APID or AOBC
+    - GSC: GS から MOBC に届き， MOBC でエンキューされずに，そのまま AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で GSC としてキューイング & 実行される．
+    - TLC: GS から MOBC に届き， MOBC でエンキューされずに，そのまま AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で TLC としてキューイング & 実行される．
+    - BC: GS から MOBC に届き， MOBC で BC 登録されずに，そのまま AOBC へ配送される．配送時， Destination Type は自分宛 (TO_ME) に上書きされ， AOBC で BC として登録 & 実行される．
 - 地上局 SW での実装まとめ
-    - MOBC 宛
-        - APID: APID_MOBC_CMD
-        - CCP_DEST_TYPE: CCP_DEST_TYPE_TO_ME
-    - AOBC 宛（AOBC 直送）
-        - APID: APID_AOBC_CMD
-        - CCP_DEST_TYPE: CCP_DEST_TYPE_TO_AOBC
-    - AOBC 宛（MOBC でキューに入り，実行時に AOBC に転送）
-        - APID: APID_AOBC_CMD
-        - CCP_DEST_TYPE: CCP_DEST_TYPE_TO_ME
+  - MOBC 宛
+    - APID: APID_MOBC_CMD
+    - CCP_DEST_TYPE: CCP_DEST_TYPE_TO_ME
+  - AOBC 宛（AOBC 直送）
+    - APID: APID_AOBC_CMD
+    - CCP_DEST_TYPE: CCP_DEST_TYPE_TO_AOBC
+  - AOBC 宛（MOBC でキューに入り，実行時に AOBC に転送）
+    - APID: APID_AOBC_CMD
+    - CCP_DEST_TYPE: CCP_DEST_TYPE_TO_ME
 
 
 ## Common Packet の定義方法
diff --git a/docs/core/tips.md b/docs/core/tips.md
index 4e09f82cb..588021040 100644
--- a/docs/core/tips.md
+++ b/docs/core/tips.md
@@ -9,14 +9,14 @@ C2A Coreを理解する上で，混乱しやすいポイントをまとめる．
 - cycleは実質的なOBCの最小時間分解能であり，stepはOBCのCPUリソースをどう分割するかを管理する．
 - したがって，Applicaionなどが識別できる時間はcycleである．
 - stepはTaskListでの時間配分を規定し得ている．
-    - 言い換えると，単一スレッドのC2Aにおける，Applicationの時分割を司っている．
+  - 言い換えると，単一スレッドのC2Aにおける，Applicationの時分割を司っている．
 - なお，Block Command Table上では，時刻データは無次元である．
-    - これがcycleなのかstepなのかはコンテスト依存（Dispatcher依存）であるので，注意が必要
+  - これがcycleなのかstepなのかはコンテスト依存（Dispatcher依存）であるので，注意が必要
 
 
 ## コマンドの実行主体
 - C2Aにおいて処理の最小単位はコマンドである．
 - TaskListでも，Applicationが並んでるようにみえるが，実際はApplicationのexecutorを叩くコマンドが発行されているのが実体．
-    - つまり，TDSPが実行してるのはコマンド．
+  - つまり，TDSPが実行してるのはコマンド．
 - しかし，TLC，RTC，GSCなどのその他各種コマンドはすべて，ApplicationとしてのDispatcherが実行している．
-    - 言い換えると，一般的なコマンドはTDSPから直接実行されていないが，例外的にTaskListだけApplicationではなくTDSPで実行されている．
+  - 言い換えると，一般的なコマンドはTDSPから直接実行されていないが，例外的にTaskListだけApplicationではなくTDSPで実行されている．
diff --git a/docs/general/coding_rule.md b/docs/general/coding_rule.md
index cbd72756e..61e7440b1 100644
--- a/docs/general/coding_rule.md
+++ b/docs/general/coding_rule.md
@@ -114,16 +114,16 @@ git blame を使うことで，該当ファイルの各行がいつ変更され
   - 実際の crate 名とディレクトリ名を合わせるため．
     - ディレクトリ名を必ず crate 名と合わせないといけないわけではない．例えば，ディレクトリ名では `c2a-` prefix を削る，といったことはある．
 - それ以外のディレクトリ名は基本的に小文字の `snake_case` ．
-    - ただし，外部ライブラリについてはこの限りではない．
-        - 例えば，`hoge-lib` のようなリポジトリ名のライブラリを Git submodule などで配置するときは，元の名前をのままにすることが望ましい．
-    - また，移行期間につき，先頭大文字の `CamelCase` （以前の規約）でも構わないものとする．
+  - ただし，外部ライブラリについてはこの限りではない．
+    - 例えば，`hoge-lib` のようなリポジトリ名のライブラリを Git submodule などで配置するときは，元の名前をのままにすることが望ましい．
+  - また，移行期間につき，先頭大文字の `CamelCase` （以前の規約）でも構わないものとする．
 - ファイル名は小文字の `snake_case`
-    - C言語では，ファイル名がユニークではないといけない処理系があるため，[後述する各論](#個別箇所についての命名など-m)にて必要な接頭辞をつけること．
+  - C言語では，ファイル名がユニークではないといけない処理系があるため，[後述する各論](#個別箇所についての命名など-m)にて必要な接頭辞をつけること．
 
 
 ### スタイル [F]
 - インデントは空白2つを単位とする．
-    - いかなる場合も tab は許可しない．
+  - いかなる場合も tab は許可しない．
 - スタイルは[Allman style](https://en.wikipedia.org/wiki/Indent_style#Allman_style)に倣う．
 ```cpp
 while (x == y)
@@ -137,8 +137,8 @@ finalthing();
 
 ### 文字コード
 - 文字コードは基本的に UTF-8 で統一する．
-    - 一部のバッチファイルなど， Shift-JIS のほうが圧倒的に楽なものについては例外を認める．
-    - User側で Shift-JIS などを要求する場合 (HEW など) は， User 側のビルドワークフローで変換するなどで対応する．
+  - 一部のバッチファイルなど， Shift-JIS のほうが圧倒的に楽なものについては例外を認める．
+  - User側で Shift-JIS などを要求する場合 (HEW など) は， User 側のビルドワークフローで変換するなどで対応する．
 - 改行コードはCR+LFで統一する．
 
 
@@ -158,17 +158,17 @@ C言語は名前空間を切ることができず，各種命名が global 空
 - なお，コマンド，テレメトリとなる関数はこの限りではない．
 - staticなものは接尾辞 `_` をつける．
 - priavteな気持ちで設計したメンバは接尾辞 `_` をつける．
-    - C言語なので private という概念は存在しないが，気持ちとして．
+  - C言語なので private という概念は存在しないが，気持ちとして．
 - ハンガリアン記法は禁止．
-    - ポインタを表す `p_` は，原則禁止だが，特別見にくいなど理由があれば許可する．
+  - ポインタを表す `p_` は，原則禁止だが，特別見にくいなど理由があれば許可する．
 
 例外：
 
 - コマンドは `Cmd_${PREFIX}_SNAKE_CASE`
 - テレメトリは `Tlm_${TLM_NAME}_`
 - 定数は `kCamelCase`
-    - const がついたらすべて定数というわけではない．
-    - constexpr あるいは const として宣言され，プログラムの始めから終わりまで値が変わらない変数のことで，関数の const をつけた引数などは該当しない．
+  - const がついたらすべて定数というわけではない．
+  - constexpr あるいは const として宣言され，プログラムの始めから終わりまで値が変わらない変数のことで，関数の const をつけた引数などは該当しない．
 
 例：
 ```cpp
@@ -184,8 +184,8 @@ extern const uint32_t FLASH_kMeiseiBlockBegin;
 - 基本的に先頭大文字の `CamelCase`
 - 構造体名，Class 名は先頭大文字の `CamelCase` [C++]
 - enum 名は例外的に大文字の `SNAKE_CASE` [C++]
-    - enum については，複雑なため，[enumの項](#enum)を参照すること．
-    - C++ 本格移行時に修正する．
+  - enum については，複雑なため，[enumの項](#enum)を参照すること．
+  - C++ 本格移行時に修正する．
 - 基本型に `typedef` を使用する場合は `snake_case_t`
 
 例：
@@ -262,9 +262,9 @@ int Cmd_APP_DR_SET_PARAMS(const CommonCmdPacket* packet);
 ### applications/component_service
 - ファイル名は `csrv_${IFやデバイス名}`
 - Driver 構造体名とそのインスタンス名を一致させる（スタイルを除く）
-    - 特定のドライバ構造体のインスタンスが複数ある場合は，配列にまとめる．
-    - 単一の場合は，スカラ形式を推奨するが，要素1の配列にしても良い．
-        - その場合，その C2A 内ではすべてのドライバ構造体のインスタンスは配列にすること．
+  - 特定のドライバ構造体のインスタンスが複数ある場合は，配列にまとめる．
+  - 単一の場合は，スカラ形式を推奨するが，要素1の配列にしても良い．
+    - その場合，その C2A 内ではすべてのドライバ構造体のインスタンスは配列にすること．
 - 接頭辞は `CSRV_${IFやデバイス名}`
 
 例：
@@ -503,9 +503,9 @@ default:
 #### その他
 - ロジック的に確実に到達しない部分にコードを書かない．
 - 書き忘れであるのか，意図しているのかがわかりにくいため，以下のルールを設ける．
-    - `else if` の伴う `if` において，`else` ブロックのないものは禁止
-        - `else` ブロックを作り， `// NOT REACHED` などのコメントを残す
-    - 同様に `default` ブロックのない `switch` も禁止
+  - `else if` の伴う `if` において，`else` ブロックのないものは禁止
+    - `else` ブロックを作り， `// NOT REACHED` などのコメントを残す
+  - 同様に `default` ブロックのない `switch` も禁止
 
 
 ### 改行など [W, F]
@@ -560,25 +560,25 @@ C++ システムヘッダ
 ## 安全のために [M]
 ### 関数の引数関連
 - 受け取ったら原則必ず assertion を行う．
-    - 引数が想定範囲内のものであるか？（配列の長さ，値の範囲など）
-    - 範囲外であれば，適切に処理する．
-    - 関数呼び出しは入れ子になっていくが，一貫した assertion を行うこと．返り値なども一貫したものにすること．
-        - enum で定義するとか，エラー情報格納構造体をやり取りするとか．最近のコード（2021年以降）を参考にすること．
+  - 引数が想定範囲内のものであるか？（配列の長さ，値の範囲など）
+  - 範囲外であれば，適切に処理する．
+  - 関数呼び出しは入れ子になっていくが，一貫した assertion を行うこと．返り値なども一貫したものにすること．
+    - enum で定義するとか，エラー情報格納構造体をやり取りするとか．最近のコード（2021年以降）を参考にすること．
 - 参照渡しで呼び出し元からみて変更されないことを保障すべきものは const 修飾子を付けておくこと．
 - 関数内で変更しない引数は const 修飾子を付けておくこと．[W]
-    - 基本型の値渡しにおいては，必ずしも const を付ける必要はない．
+  - 基本型の値渡しにおいては，必ずしも const を付ける必要はない．
 
 
 ### 関数の戻り値関連
 - 返り値は必ず assertion を行う．
-    - 全体として一貫した管理がなされている関数群ではこの限りではない．
+  - 全体として一貫した管理がなされている関数群ではこの限りではない．
 - 使わない返り値は void にキャストして，以後使わないことを明示する．
 - 返り値として bool を使うことは非推奨 [W]
-    - なにが true/false なのかは一意ではないことが多いため．
-    - 代わりに enum を使い，その名前が説明的であることが望ましい．
+  - なにが true/false なのかは一意ではないことが多いため．
+  - 代わりに enum を使い，その名前が説明的であることが望ましい．
 - 値を返すものにエラーコードを混ぜない [W]
-    - get_address の返り値が正だと address で負だとエラーコード，といったものは一貫性がないので禁止する．
-    - 例えば，一連の関数群の返り値はエラーコードに統一し，値はポインタで返すことで対応する．
+  - get_address の返り値が正だと address で負だとエラーコード，といったものは一貫性がないので禁止する．
+  - 例えば，一連の関数群の返り値はエラーコードに統一し，値はポインタで返すことで対応する．
 
 
 ## 各機能について [M]
@@ -672,21 +672,21 @@ typedef enum
 ### `#define` の使用について
 - `.h` 内においての定義は，他でも利用されるものに限る．
 - `.c` 内での定義は， `static const` 変数に置き換えられないか考えること．
-    - `static const` であればメモリ上に展開されるため，memload による再プロが可能．
-    - 逆に言うと，それによってメモリ配置やサイズが変わるものなど，再プロ出来ないものは `#define` が望ましい．
+  - `static const` であればメモリ上に展開されるため，memload による再プロが可能．
+  - 逆に言うと，それによってメモリ配置やサイズが変わるものなど，再プロ出来ないものは `#define` が望ましい．
 
 
 
 ## コミット時，マージ時に守るべきこと [M]
 - PR 発行時には，最低限，実機開発環境でビルドできることは確認する．
-    - 一度作業ブランチを最新 develop に rebase し，その状態でビルドできることを確認するのがベスト．
+  - 一度作業ブランチを最新 develop に rebase し，その状態でビルドできることを確認するのがベスト．
 - AppRegistry への追加などをマージして良いのは，実機試験を行った後に限る．
 - 不要な include はビルド時間を不必要に増大させるので，消すこと．
 - git のお作法については，git 関連資料を参照すること．
-    - branch 方針や，merge 方針，Pull Request，issue など．
-    - 適当に web にあるものや，研究室 wiki，git 講習会資料などを参照．
+  - branch 方針や，merge 方針，Pull Request，issue など．
+  - 適当に web にあるものや，研究室 wiki，git 講習会資料などを参照．
 - そのマージリクエストのスコープを意識すること．
-    - スコープ外の修正が入ってませんか？ PRを 分割しましょう． [W]
+  - スコープ外の修正が入ってませんか？ PRを 分割しましょう． [W]
 
 
 
@@ -697,13 +697,13 @@ typedef enum
 
 ### 全般
 - ハードウェアに依存する書き方をしないこと．
-    - 通信や特定のデバイス利用に関しては，hal フォルダ直下の関数を用いれば問題ない．
-    - もちろん，マイコンのレジスタの操作などを直接書くとパソコンでは動かせなくなる．
+  - 通信や特定のデバイス利用に関しては，hal フォルダ直下の関数を用いれば問題ない．
+  - もちろん，マイコンのレジスタの操作などを直接書くとパソコンでは動かせなくなる．
 - エンディアンの違い
-    - ほとんどのパソコンがリトルエンディアンなのに対し，いくつかのマイコンはビッグエンディアンである．
-        - 当然バイトオーダーは異なるし，ビットフィールドの並びも異なる．
-        - ドライバなどで，バイト列を int や float に変換するところなどは要注意．
-    - エンディアンに依存しないコードを書くか，以下のような定義を適切に使うこと．また，`ENDIAN_memcpy` などといった共用関数を積極的に利用すること．
+  - ほとんどのパソコンがリトルエンディアンなのに対し，いくつかのマイコンはビッグエンディアンである．
+    - 当然バイトオーダーは異なるし，ビットフィールドの並びも異なる．
+    - ドライバなどで，バイト列を int や float に変換するところなどは要注意．
+  - エンディアンに依存しないコードを書くか，以下のような定義を適切に使うこと．また，`ENDIAN_memcpy` などといった共用関数を積極的に利用すること．
 - `SILS_FW` と `IS_LITTLE_ENDIAN` を混同して使わないこと
 ```cpp
 #ifndef SILS_FW
@@ -724,39 +724,39 @@ typedef enum
 
 ### その他
 - コメント
-    - `// hoge` のように，`//` の後には空白を入れること．
+  - `// hoge` のように，`//` の後には空白を入れること．
 - ファイル末尾には必ず空行を入れること．
-    - Unexpected EOFのエラーを防ぐため．
+  - Unexpected EOFのエラーを防ぐため．
 
 
 ### VC++コンパイラに関する注意
 - コメントについて
-    - VC++ コンパイラでは，下記のコメントはエラーになるので使用しない．
-        - `//**********************************`
-        - `/*` が閉じていないと解釈されるためと思われる．
-        - 過去衛星のコードでは多用されていたため，暫定的に全て `// ******` に置換した．
+  - VC++ コンパイラでは，下記のコメントはエラーになるので使用しない．
+    - `//**********************************`
+    - `/*` が閉じていないと解釈されるためと思われる．
+    - 過去衛星のコードでは多用されていたため，暫定的に全て `// ******` に置換した．
 - C++ ビルドを行う上で HEW コンパイラではビルドが通るが注意しなければならない点をまとめる．
-    - const ポインタを const ではないポインタに代入してはいけない．
-        - これが発生するときは，設計が間違っているか，const で良い変数を const にし忘れている．
-            - 本来設計が間違っていれば修正をすべきだが，どうしてもの場合はCのキャストで const を外し，`const_cast` といったコメントを入れる．
-                - 例) `PL_Node *pos = (PL_Node*)PL_get_head(&(tl_cmd_list[line_no])); // const_cast`
-    - C++ の予約語は変数や関数名に使用してはいけない
-        - 過去にあった例は `virtual` や `new` といった変数．
+  - const ポインタを const ではないポインタに代入してはいけない．
+    - これが発生するときは，設計が間違っているか，const で良い変数を const にし忘れている．
+      - 本来設計が間違っていれば修正をすべきだが，どうしてもの場合はCのキャストで const を外し，`const_cast` といったコメントを入れる．
+        - 例) `PL_Node *pos = (PL_Node*)PL_get_head(&(tl_cmd_list[line_no])); // const_cast`
+  - C++ の予約語は変数や関数名に使用してはいけない
+    - 過去にあった例は `virtual` や `new` といった変数．
 - コンパイラのワーニングについて
-    - 警告レベルを3以上に設定し，そのワーニングはすべてエラーとして扱うことにする．
+  - 警告レベルを3以上に設定し，そのワーニングはすべてエラーとして扱うことにする．
 - その他 Windows について
-    - `#pragma once` の利用は禁止．
+  - `#pragma once` の利用は禁止．
 
 
 ### HEWコンパイラに関する注意
 - コンパイラバージョンの違い
-    - 最新の VC++ が C99 に準拠しているのに対し，HEW のコンパイラは C89 準拠なので，古い書き方を強制される．
-    - 例えば：
-        - 関数内変数の宣言は，全て関数の頭で行わなければならない．
-            - `for (int i = 0; i < 10; i++)` みたいなのは `i` の宣言部でコンパイルエラーになる
-        - include 忘れで関数定義がなくてもコンパイルが通ってしまう．
+  - 最新の VC++ が C99 に準拠しているのに対し，HEW のコンパイラは C89 準拠なので，古い書き方を強制される．
+  - 例えば：
+    - 関数内変数の宣言は，全て関数の頭で行わなければならない．
+      - `for (int i = 0; i < 10; i++)` みたいなのは `i` の宣言部でコンパイルエラーになる
+    - include 忘れで関数定義がなくてもコンパイルが通ってしまう．
 - コンパイラのワーニングについて
-    - もっとも強いコンパイラオプションにし，すべてエラーとして扱うことにする．
+  - もっとも強いコンパイラオプションにし，すべてエラーとして扱うことにする．
 
 
 
@@ -827,20 +827,20 @@ memload などによる部分的な再プロをやりやすくするため．
 ### その他細かなこと [W]
 - 予約語の前後は空白をいれる．`(),{}` などの外側も空白を入れる．二項演算子の両側にも空白をいれる． [M,F]
 - 見やすく書く．
-    - 一行を長くしすぎない．
-    - 適切に中間変数を置くことで，処理を追いやすくする．
-        - 変数には変数名がつくので，わかりやすくなる．
-    - など
+  - 一行を長くしすぎない．
+  - 適切に中間変数を置くことで，処理を追いやすくする．
+    - 変数には変数名がつくので，わかりやすくなる．
+  - など
 - 意味のないものは書かない．逆に書いたものには意味がある．
-    - 意味のない修正は git log のノイズになることに留意すること．またマージ時に不要なコンフリクトを生じさせることにもつながる．
-    - 不要な空白をいれない．[M]
-        - 特に目につくのは行末や空行のインデント．
-    - 不要な文字列やコードを書かない．[M]
-        - `;` などが不要な場所にあったとしてもコンパイルは通るが，意味がないのできちんと消すこと．
-    - 意味もなく多数（３行程度以上）の空行を入れない．空行の行数には意味があること．[M]
-        - ひとまとまりの処理を１行空行をいれ，さらに大きな区切りや関数区切りに２行の空行をいれる，など．
+  - 意味のない修正は git log のノイズになることに留意すること．またマージ時に不要なコンフリクトを生じさせることにもつながる．
+  - 不要な空白をいれない．[M]
+    - 特に目につくのは行末や空行のインデント．
+  - 不要な文字列やコードを書かない．[M]
+    - `;` などが不要な場所にあったとしてもコンパイルは通るが，意味がないのできちんと消すこと．
+  - 意味もなく多数（３行程度以上）の空行を入れない．空行の行数には意味があること．[M]
+    - ひとまとまりの処理を１行空行をいれ，さらに大きな区切りや関数区切りに２行の空行をいれる，など．
 - そのコードが担うべきスコープを意識すること．
-    - その処理は本当にそこでやるべきですか？
+  - その処理は本当にそこでやるべきですか？
 
 
 ### メタコメント [M]
@@ -863,7 +863,7 @@ memload などによる部分的な再プロをやりやすくするため．
 - TBA などを参照のこと．
 - その他は，最近コミットされたものを参考にすること．
 - 方針としては， `.h` として公開される関数は必ず `.h` の関数定義に記入すること．
-    - 自明な getter/setter はその限りではない．なお，このとき，getter/setter の対象となるメンバの宣言に，きちんとしたコメントが書いてあることが必須．
+  - 自明な getter/setter はその限りではない．なお，このとき，getter/setter の対象となるメンバの宣言に，きちんとしたコメントが書いてあることが必須．
 - その他の static 関数類も，重要なもの，複雑なものは書くこと（基本的には書いてほしい）．
 
 ### フォーマッタ
diff --git a/docs/general/release.md b/docs/general/release.md
index 716724930..10ecda630 100644
--- a/docs/general/release.md
+++ b/docs/general/release.md
@@ -5,38 +5,38 @@
 リリースには，本 Release と Pre-release の２つを設ける．
 
 - 本 Release
-    - まとまった機能更新のリリース．
-    - バージョンを上げる．
-    - `v3.4.0` → `v3.5.0` など
+  - まとまった機能更新のリリース．
+  - バージョンを上げる．
+  - `v3.4.0` → `v3.5.0` など
 - Pre-release
-    - [Tools/Overview](../tools/overview.md) などに対して非互換なアップデートが入った場合や，Bug fix や 大きな機能更新などで，本 Release 前に User サイドで最新の Core が必要になることが予想される際のリリース．
-    - `beta` をリリースする．
-        - `v3.4.0` → `v3.5.0-beta.0` など
-    - なお，メジャーバージョンアップ中では様々な破壊的な変更が連続するため，煩雑さ低減のためにツール等の互換性維持のための Pre-release は，一定程度免除することが可能である．
+  - [Tools/Overview](../tools/overview.md) などに対して非互換なアップデートが入った場合や，Bug fix や 大きな機能更新などで，本 Release 前に User サイドで最新の Core が必要になることが予想される際のリリース．
+  - `beta` をリリースする．
+    - `v3.4.0` → `v3.5.0-beta.0` など
+  - なお，メジャーバージョンアップ中では様々な破壊的な変更が連続するため，煩雑さ低減のためにツール等の互換性維持のための Pre-release は，一定程度免除することが可能である．
 
 リリースの手順は以下のようにする．
 
 ### 本 Release
 
 1. バージョン番号をインクリメントする PR (Pull Request) を発行し，`develop` ブランチへ merge する．
-    - [c2a_core_main.h](https://github.com/arkedge/c2a-core/blob/develop/c2a_core_main.h) 内の `C2A_CORE_VER_*` をインクリメントする．
-    - [Cargo.toml](https://github.com/arkedge/c2a-core/blob/develop/Cargo.toml) 内の `workspace.package.version` をインクリメントする．
-    - この後リリースを控えるので，念の為すべてのテストを再度回す．
-    - `#define C2A_CORE_VER_PRE` は `("")` とする．
-    - PR タイトルは `Update version (v3.4.0)` のようにする．
-    - 例: https://github.com/ut-issl/c2a-core/pulls?q=is%3Apr+Update+version
+   - [c2a_core_main.h](https://github.com/arkedge/c2a-core/blob/develop/c2a_core_main.h) 内の `C2A_CORE_VER_*` をインクリメントする．
+   - [Cargo.toml](https://github.com/arkedge/c2a-core/blob/develop/Cargo.toml) 内の `workspace.package.version` をインクリメントする．
+   - この後リリースを控えるので，念の為すべてのテストを再度回す．
+   - `#define C2A_CORE_VER_PRE` は `("")` とする．
+   - PR タイトルは `Update version (v3.4.0)` のようにする．
+   - 例: https://github.com/ut-issl/c2a-core/pulls?q=is%3Apr+Update+version
 1. バージョン上げ PR が merge されたら，直ちに（他の PR を止め） `develop` から `main` に PR を発行し，すべてのテストを回し， merge する．
-    - PR タイトルは以下のようにする．
-        - `Update main (v3.4.0) on 2021-12-31`
-        - `Update main (v3.4.0) on 2021-12-31 - ほげほげ`
-    - PR のディスクリプションは [これ](https://github.com/ut-issl/c2a-core/pull/151) のように書く．
-    - 例: https://github.com/ut-issl/c2a-core/pulls?q=is%3Apr+Update+main
+   - PR タイトルは以下のようにする．
+     - `Update main (v3.4.0) on 2021-12-31`
+     - `Update main (v3.4.0) on 2021-12-31 - ほげほげ`
+   - PR のディスクリプションは [これ](https://github.com/ut-issl/c2a-core/pull/151) のように書く．
+   - 例: https://github.com/ut-issl/c2a-core/pulls?q=is%3Apr+Update+main
 1. [tag](https://github.com/ut-issl/c2a-core/tags) を打ち， [release](https://github.com/ut-issl/c2a-core/releases) を発行する．
-    - tag 名は `v3.4.0` のようにする．
-    - release 名は `v3.4.0` や `v3.3.1 初版` のようにする．
-    - release には以下を含める．
-        - Release Note として簡潔な更新差分の箇条書き
-        - `main` に merge したときの PR のリンク
+   - tag 名は `v3.4.0` のようにする．
+   - release 名は `v3.4.0` や `v3.3.1 初版` のようにする．
+   - release には以下を含める．
+     - Release Note として簡潔な更新差分の箇条書き
+     - `main` に merge したときの PR のリンク
 1. `cargo publish` する．
 
 これを，だいたい以下のような粒度で行う．
@@ -48,20 +48,20 @@
 
 ### Pre-release
 1. ある `feature` ブランチから `develop` ブランチへの PR が発行されたとき，それが Pre-release に相当する場合，その PR は Pre-release PR と呼び，次のような手順を踏む．
-    - PR タイトルは以下のようにする．
-        - `Pre Release (v3.5.0-beta.0): 通常のPRのタイトル`
-    - 対応する Tools の PR のリンクを貼る．
-    - `#define C2A_CORE_VER_PRE` に `("beta.0")` などをセットする．
-    - 本 Release 後最初の Pre-release の場合， `C2A_CORE_VER_*` をインクリメントする．
-    - [Cargo.toml](https://github.com/arkedge/c2a-core/blob/develop/Cargo.toml) 内の `package.version` を同様にインクリメントする．
-    - 例: https://github.com/ut-issl/c2a-core/pulls?q=is%3Apr+Pre+Release
+   - PR タイトルは以下のようにする．
+     - `Pre Release (v3.5.0-beta.0): 通常のPRのタイトル`
+   - 対応する Tools の PR のリンクを貼る．
+   - `#define C2A_CORE_VER_PRE` に `("beta.0")` などをセットする．
+   - 本 Release 後最初の Pre-release の場合， `C2A_CORE_VER_*` をインクリメントする．
+   - [Cargo.toml](https://github.com/arkedge/c2a-core/blob/develop/Cargo.toml) 内の `package.version` を同様にインクリメントする．
+   - 例: https://github.com/ut-issl/c2a-core/pulls?q=is%3Apr+Pre+Release
 1. [tag](https://github.com/ut-issl/c2a-core/tags) を打ち， [release](https://github.com/ut-issl/c2a-core/releases) を Pre-release として発行する．
-    - Pre-release PR を merge したその merge commit（`develop` ブランチ上）で tag を打つ．
-    - tag 名は `v3.5.0-beta.0` のようにする．
-    - release 名は `v3.5.0-beta.0` のようにする．
-    - release には以下を含める．
-        - 非互換となった Tools の新しい バージョン (Release) へのリンク
-        - `develop` に merge したときの PR のリンク
+   - Pre-release PR を merge したその merge commit（`develop` ブランチ上）で tag を打つ．
+   - tag 名は `v3.5.0-beta.0` のようにする．
+   - release 名は `v3.5.0-beta.0` のようにする．
+   - release には以下を含める．
+     - 非互換となった Tools の新しい バージョン (Release) へのリンク
+     - `develop` に merge したときの PR のリンク
 1. `cargo publish` する．
 
 
@@ -75,9 +75,9 @@ Tool のリリースには，以下に注意する．
 
 - C2A と同様の規則で Relase を発行する．
 - release には以下を含める．
-    - Release Note として簡潔な更新差分の箇条書き
-    - 対応する最小 C2A Core バージョン
-    - この Tool に適合させたときの C2A Core の PR へのリンク
+  - Release Note として簡潔な更新差分の箇条書き
+  - 対応する最小 C2A Core バージョン
+  - この Tool に適合させたときの C2A Core の PR へのリンク
 
 例:
 
diff --git a/docs/tips/parameter_settings.md b/docs/tips/parameter_settings.md
index cbb6bccc6..a6377042e 100644
--- a/docs/tips/parameter_settings.md
+++ b/docs/tips/parameter_settings.md
@@ -12,16 +12,16 @@ FIXME: 2021/12/04現在，だいぶ情報が古いので更新する．
 
 ## 目次
 - [C2Aのメモリ使用量に大きく影響する設定](#c2aのメモリ使用量に大きく影響する設定)
-    - [block_command_table_params](#block_command_table_params)
-    - [packet_handler_params](#packethandlerparams)
-    - [driver_super_params](#driver_super_params)
+  - [block_command_table_params](#block_command_table_params)
+  - [packet_handler_params](#packethandlerparams)
+  - [driver_super_params](#driver_super_params)
 - [メモリ使用量にあまり影響しない設定](#メモリ使用量にあまり影響しない設定)
-    - [command_analyze_params](#command_analyze_params)
-    - [telemetry_frame_params](#telemetry_frame_params)
-    - [event_logger_params](#event_logger_params)
-    - [event_handler_params](#event_handler_params)
-    - [app_manager_params](#app_manager_params)
-    - [obc_time_params](#obc_time_params)
+  - [command_analyze_params](#command_analyze_params)
+  - [telemetry_frame_params](#telemetry_frame_params)
+  - [event_logger_params](#event_logger_params)
+  - [event_handler_params](#event_handler_params)
+  - [app_manager_params](#app_manager_params)
+  - [obc_time_params](#obc_time_params)
 
 
 ## C2Aのメモリ使用量に大きく影響する設定
diff --git a/examples/mobc/src/src_user/hal/sils_mockup/README.md b/examples/mobc/src/src_user/hal/sils_mockup/README.md
index bf26c57a7..ef8536adb 100644
--- a/examples/mobc/src/src_user/hal/sils_mockup/README.md
+++ b/examples/mobc/src/src_user/hal/sils_mockup/README.md
@@ -1,6 +1,6 @@
 # SILS MOCKUP
 - C2A Core 開発のために， Core 単体で C89 ビルドするための HAL Mockup
-    - Core 開発では特定のハードウェアを仮定できないので， SILS を用いるが，現在のデフォルトの SILS である S2E は， C++ ビルドを行う．
-    - それでは， C89 の Core のコンパイルエラー，ワーニングのチェックができないため，非環境依存の Mockup を用いて， C89 ビルドする環境を用意したものがこれ．
-    - 検証したいコードは `src_user/hal/sils` には存在しないはずなので，ビルドのみで実行しないのであれば，これで良い．
+  - Core 開発では特定のハードウェアを仮定できないので， SILS を用いるが，現在のデフォルトの SILS である S2E は， C++ ビルドを行う．
+  - それでは， C89 の Core のコンパイルエラー，ワーニングのチェックができないため，非環境依存の Mockup を用いて， C89 ビルドする環境を用意したものがこれ．
+  - 検証したいコードは `src_user/hal/sils` には存在しないはずなので，ビルドのみで実行しないのであれば，これで良い．
 - 参考: https://github.com/ut-issl/c2a-core/issues/27
diff --git a/examples/mobc/src/src_user/test/README.md b/examples/mobc/src/src_user/test/README.md
index e6b346981..9aaed08e0 100644
--- a/examples/mobc/src/src_user/test/README.md
+++ b/examples/mobc/src/src_user/test/README.md
@@ -5,9 +5,9 @@
 
 ## 環境
 - python3 系列と以下のライブラリ
-    - [python-wings-interface](https://github.com/ut-issl/python-wings-interface)
-    - [c2a-enum-loader](../../../../../enum-loader/)
-    - [c2a-pytest-gaia](https://github.com/arkedge/c2a-pytest-gaia)
+  - [python-wings-interface](https://github.com/ut-issl/python-wings-interface)
+  - [c2a-enum-loader](../../../../../enum-loader/)
+  - [c2a-pytest-gaia](https://github.com/arkedge/c2a-pytest-gaia)
 - 上記の Python 環境は [rye](https://rye-up.com/) を用いてセットアップすること
 - C2A実行環境（特定のボードでもSILSでも可）
 - Gaia or WINGS（`utils/wings_utils.py` を以前のものに戻せばまだ使える）
@@ -16,8 +16,8 @@
 ### フォルダ構成
 - C2A と揃える．
 - ファイル名は， `test_${c2a_src_filename}.py`．例えば次のようなもの．
-    - './src_core/applications/test_nop.py'
-    - './src_user/applications/user_defined/test_tlm_mem_dump.py'
+  - './src_core/applications/test_nop.py'
+  - './src_user/applications/user_defined/test_tlm_mem_dump.py'
 
 ### 関数名
 `test_hoge` という関数を定義すれば，それが実行される．
@@ -55,4 +55,4 @@ rye run pytest -m real -v ./src_user/applications/user_defined/test_tlm_mem_dump
 
 ## WINGS を使った実行時の補足
 - デフォルトで，WINGS へのデータ送信が無効となっているため，以下を ON にする必要がある．
-    - https://github.com/arkedge/c2a-core/blob/eba25277c16ed50a79610eb9a34c62317a0e0141/examples/mobc/CMakeLists.txt#L11
+  - https://github.com/arkedge/c2a-core/blob/eba25277c16ed50a79610eb9a34c62317a0e0141/examples/mobc/CMakeLists.txt#L11
diff --git a/examples/subobc/src/src_user/hal/sils_mockup/README.md b/examples/subobc/src/src_user/hal/sils_mockup/README.md
index bf26c57a7..ef8536adb 100644
--- a/examples/subobc/src/src_user/hal/sils_mockup/README.md
+++ b/examples/subobc/src/src_user/hal/sils_mockup/README.md
@@ -1,6 +1,6 @@
 # SILS MOCKUP
 - C2A Core 開発のために， Core 単体で C89 ビルドするための HAL Mockup
-    - Core 開発では特定のハードウェアを仮定できないので， SILS を用いるが，現在のデフォルトの SILS である S2E は， C++ ビルドを行う．
-    - それでは， C89 の Core のコンパイルエラー，ワーニングのチェックができないため，非環境依存の Mockup を用いて， C89 ビルドする環境を用意したものがこれ．
-    - 検証したいコードは `src_user/hal/sils` には存在しないはずなので，ビルドのみで実行しないのであれば，これで良い．
+  - Core 開発では特定のハードウェアを仮定できないので， SILS を用いるが，現在のデフォルトの SILS である S2E は， C++ ビルドを行う．
+  - それでは， C89 の Core のコンパイルエラー，ワーニングのチェックができないため，非環境依存の Mockup を用いて， C89 ビルドする環境を用意したものがこれ．
+  - 検証したいコードは `src_user/hal/sils` には存在しないはずなので，ビルドのみで実行しないのであれば，これで良い．
 - 参考: https://github.com/ut-issl/c2a-core/issues/27
diff --git a/examples/subobc/src/src_user/test/README.md b/examples/subobc/src/src_user/test/README.md
index 2c150c283..8d0ce86f0 100644
--- a/examples/subobc/src/src_user/test/README.md
+++ b/examples/subobc/src/src_user/test/README.md
@@ -13,17 +13,17 @@ pytest は subobc 側（このディレクトリ）で実行する．
 
 ## テスト用の S2E を用いた SILS 構成（WINGS 版）
 - WINGS に， MOBC と AOBC の両方の TlmCmd DB を登録する．
-    - WINGS の使い方は WINGS Document を参照すること．
+  - WINGS の使い方は WINGS Document を参照すること．
 - SILS 環境 [S2E User for C2A Core](https://github.com/ut-issl/s2e-user-for-c2a-core) を 2 セット準備し， MOBC，AOBC それぞれを立ち上げる．
-    - S2E の使い方は S2E Document を参照すること．
-    - この時， MOBC の CCSDS ポートは WINGS の仮想ポートに接続（ループバック）し， MOBC の UART ポートは AOBC の UART ポートに接続（ループバック）させる．
-    - MOBC / AOBC 側で WINGS への COM ポートへの出力を有効化するために，以下を ON にする．
-        - https://github.com/arkedge/c2a-core/blob/eba25277c16ed50a79610eb9a34c62317a0e0141/examples/mobc/CMakeLists.txt#L11
-        - https://github.com/arkedge/c2a-core/blob/eba25277c16ed50a79610eb9a34c62317a0e0141/examples/subobc/CMakeLists.txt#L11
-    - MOBC 側で AOBC への COM ポートへの出力を有効化するために，以下を ON にする．
-        - https://github.com/arkedge/c2a-core/blob/eba25277c16ed50a79610eb9a34c62317a0e0141/examples/mobc/CMakeLists.txt#L17
-    - デフォルトでは，以下のようになっている．
-        - MOBC CCSDS: COM11
-        - MOBC UART: COM13
-        - AOBC UART: COM14
+  - S2E の使い方は S2E Document を参照すること．
+  - この時， MOBC の CCSDS ポートは WINGS の仮想ポートに接続（ループバック）し， MOBC の UART ポートは AOBC の UART ポートに接続（ループバック）させる．
+  - MOBC / AOBC 側で WINGS への COM ポートへの出力を有効化するために，以下を ON にする．
+    - https://github.com/arkedge/c2a-core/blob/eba25277c16ed50a79610eb9a34c62317a0e0141/examples/mobc/CMakeLists.txt#L11
+    - https://github.com/arkedge/c2a-core/blob/eba25277c16ed50a79610eb9a34c62317a0e0141/examples/subobc/CMakeLists.txt#L11
+  - MOBC 側で AOBC への COM ポートへの出力を有効化するために，以下を ON にする．
+    - https://github.com/arkedge/c2a-core/blob/eba25277c16ed50a79610eb9a34c62317a0e0141/examples/mobc/CMakeLists.txt#L17
+  - デフォルトでは，以下のようになっている．
+    - MOBC CCSDS: COM11
+    - MOBC UART: COM13
+    - AOBC UART: COM14
 - テストを実行する．