cfs_nasa_docs_20250617

https://ntrs.nasa.gov/api/citations/20205011588/down loads/TM%2020205000691%20REV%201.pdf

• https://ntrs.nasa.gov/api/citations/20205011588/down

• 1. Introduction • 2. cFE Services • a) Executive Services • b) Software Bus • c) Event Services • d) Time Services • e) Table Services • 3. Application Layer • a) cFS Applications • b) cFS Libraries • Application Build Context • Application Runtime Context • Existing Application • Application Design 5 49 65 96 125 147 166 188 191 192 193 198 202 214 214

• 1. Introduction • cFS（Core Flight System）とは • - NASAが開発した宇宙機搭載用のミドルウェア • - 「再利用性」「移植性」「モジュール性」を重視 • - 宇宙機ソフトウェアの『OSとアプリの橋渡し』を担う • cFSの目的と特徴 • - 異なるミッション・ハードウェア間で再利用可能な構成 • - サービス分離された層構造（OSAL, PSP, cFE, Apps） • - 動的アプリ起動・停止、リセット耐性、CDSなどの高信頼性 • ROSとの違い • 共通点 • - ノード間通信（Publish/Subscribe） • - オープンソース • 違い • - cFSは『実時間処理』と『高信頼性』を重視 • - 宇宙用：再起動・ログ・例外処理・Critical Data Store(CDS)などが組込済 • - ROSは開発スピード・柔軟性を重視（ロバスト性はミッション依存）

• 1. Introduction • cFSは以下のような階層構造を持つ： • RTOS（例: RTEMS, VxWorks, Linux） • OSAL（OS Abstraction Layer） • PSP（Platform Support Package） • cFE（Core Flight Executive） • アプリケーション層（ミッション機能） • → 各層が独立しており、移植性と再利用性を確保 • → 開発者が Ground System から cFE を操作しア プリケーションがハードウェアに依存せず動作 • cFSの役割：ミドルウェア • OSやハードウェアに依存しないアプリ開発を可能 に • 宇宙ミッションに共通する基盤機能を提供 • 起動/通信/ログ管理など • アプリケーションを動的に起動/停止/リセット可能 • ミドルウェアとして、機能と責任を中間層に集約 • 再利用性・移植性の設計 • OS/CPUを問わず共通APIで実装可能（OSAL, PSPによる抽象化） • モジュール設計：サービス単位で差し替え／拡張しやすい • 実例：x86/Linux, RAD750/RTEMS, LEON3/vxWorksで実績あり • ソフトウェア開発の初期段階でデスクトップ検証可

• 1. Introduction • 2. cFE Services • a) Executive Services • b) Software Bus • c) Event Services • d) Time Services • e) Table Services • 3. Application Layer • a) cFS Applications • b) cFS Libraries • Application Build Context • Application Runtime Context • Existing Application • Application Design 5 49 65 96 125 147 166 188 191 192 193 198 202 214

• Executive Services (ES) • Manages the software system and creates an application runtime environment • Software Bus (SB) Services • Provides an application publish/subscribe messaging service • Event Services (EVS) • Provides a service for sending, filtering, and logging event messages • Time Services (TIME) • Manages spacecraft time • Table Services (TBL) • Manages application table images

• 2. cFE Services • a) Executive Services • b) Software Bus • c) Event Services • d) Time Services • e) Table Services 49 65 96 125 147 166

• 2. cFE Services • a) Executive Services • b) Software Bus • c) Event Services • d) Time Services • e) Table Services 49 65 96 125 147 166

Executive Services (ES) – Overview • Initializes the cFE – Reports reset type – Maintains an exception-reset log across processor resets • Creates the application runtime environment – Primary interface to underlying operating system task services – Manages application resources – Starts initial applications according to cfe_es_startup.scr – Supports starting, stopping, and loading applications during runtime • Manages Memory – Provides a dynamic memory pool service – Provides Critical Data Stores (CDSs) that are preserved across processor resets cFS Training- Page 64

• cFS: Executive Services（ES） • CFE_ES_Main() による起動とアプリ管理 • アプリの起動・停止・再起動・削除が実行時に可能 • アプリ実行情報を記録（System Log, Exception Log） • Critical Data Store (CDS) によるプロセッサリセット後の状態保存・復旧 • タスクごとのリソース消費や統計管理も可能 • ROS 2 での類似要素 • lifecycle node • launch • rclcpp_logging • systemd（外部） • DDS middlewares ノードの起動 → 停止 → 再アクティベートの制御 起動管理（ただしプロセスの外部管理） ログ出力（ただし永続化しない） リセット時の復旧処理などはOS任せ QoSでデータ寿命など制御は可能だがCDS機能はなし

• cFS: Executive Services（ES） • 類似点と違い 類似 相違 ライフサイ クル管理 起動・停止が制御可能 ROS 2は1ノード単位／cFSはアプリ単位でかつ再起 動も制御可能 ログ機能 エラー／診断情報を残す cFSはログがリセット後も保持される（CDS） 柔軟性 どちらもアプリケーション ROS 2は柔軟性優先、cFSは信頼性と再現性優先 再構成可能 リセット処 理 N/A cFSはリセット種別の識別と復旧支援がある （Processor ResetとPower-on Reset） • もしROS 2でESのような機能を実現したい場合: • lifecycle ノード + launch + 永続化された状態保存層（例：SQLite + 状態マネージャ） • 例外ハンドリングと再起動制御はOSレベル（systemdや監視スクリプト）で補う • ログと状態は、ローカル永続ストレージ + /diagnostics などの仕組みで模倣可

Executive Services - Boot Sequence • The PROM boots the OS kernel linked with the BSP, loader and EEPROM file system. ‒ Accesses simple file system ‒ Selects primary and secondary images based on flags and checksum validation ‒ Copies OS image to RAM • The OS kernel boots the cFE ‒ Performs self – decompression (optional) ‒ Attaches to EEPROM File System ‒ Starts up cFE • cFE boots cFE interface apps and mission components (C&DH, GNC, Science applications) ‒ ‒ ‒ ‒ Creates/Attaches to Critical Data Store (CDS) Creates/Attaches to RAM File System Starts cFE services (ES, EVS, TBL, SB, & TIME) Starts the applications based on cfe_es_startup.scr Reset PROM Boot OS Kernel Boot cFE Boot FSW Init cFS Training- Page 65

Executive Services - Startup From BSP Startup Initialize OS Data structures (task table, queues etc.) Volatile File System RAM Log entry Initialize File Systems cFE Core cFS App 1 Initialize Core Applications* Non-Volatile File System Startup Script And cFE Apps/Libs Initialize cFE Apps and shared libraries (as specified in ES startup script) Start Multitasking Exception and Reset Log cFE Applications cFS App N *Note: Service initialization order: ES, EVS, SB, TIME, TBL Service start order: EVS, SB, ES, TIME, TBL The cFE core is started as one unit. The cFE Core is linked with the RTOS and support libraries and loaded into system EEPROM as a static executable. cFS Training- Page 66

Executive Services - Startup Script • The startup script is a text file, written by the user that contains a list of entries (one entry for each application) – Used by the ES application for automating the startup of applications. – ES application allows the use of a volatile and nonvolatile startup scripts. The project may utilize zero, one or two startup scripts. Object Type CFE_APP for an Application, or CFE_LIB for a library. Path/Filename This is a cFE Virtual filename, not a vxWorks device/pathname Entry Point This is the name of the "main" function for App. CFE Name The cFE name for the APP or Library Priority This is the Priority of the App, not used for a Library Stack Size This is the Stack size for the App, not used for a Library Load Address This is the Optional Load Address for the App or Library. It is currently not implemented so it should always be 0x0. This is the Action the cFE should take if the Application has an exception. Exception Action • • 0 = Do a cFE Processor Reset Non-Zero = Just restart the Application cFS Training- Page 67

Executive Services – Example Script cFS Training- Page 68

• 2. cFE Services • a) Executive Services • b) Software Bus • c) Event Services • d) Time Services • e) Table Services 49 65 96 125 147 166

Software Bus (SB) Services - Overview • Provides a portable inter-application message service using a publish/subscribe model • Routes messages to all applications that have subscribed to the message (i.e. broadcast model) – Subscriptions are done at application startup – Message routing can be added/removed at runtime – Sender does not know who subscribes (i.e. connectionless) • Reports errors detected during the transferring of messages • Outputs Statistics Packet and the Routing Information when commanded cFS Training- Page 95

• Software Bus • cFSのSoftware Bus (SB) は、ROS 2の通信ミドルウェア（DDS）やそのPublish/Subscribeと機能的に対応 • 類似点 • Publish/Subscribeモデル アプリケーション間通信を疎結合に実現 • 型ベース通信 cFSでは構造体定義、ROS 2はIDL型（msg）で通信 • ツールあり cFS: 送信/受信/ルーティングの確認、ROS 2: CLIで可視化 • 統計と監視 両者とも統計取得や診断支援が可能（cFS: Telemetry, ROS:/statistics） cFS ROS 2 対象 宇宙機内のRTOSプロセス 間通信 （分散）システムのプロセス間・ネットワーク通信 通信の想定範囲 1台のRTOS内アプリケー ション間（通常） 分散ノード間（ネット越し） QoSサポート なし あり（DDSベース、標準で） 柔軟性 静的メッセージIDとルート 設定が必要 動的にトピック生成・削除可能 冗長化/信頼性 ハードウェアやアプリレベ ルで設計 DDSが一定の自動フェイルオーバー支援 • 相違点 • cFS SBをROS 2で模倣するには？ • ROS 2 + rclcpp の標準 Publisher / Subscription を使う • メッセージID相当の制約を設けたい場合は、固定トピック名 + ヘッダ付きmsg型で模倣可 • ルーティング制御を厳密にやりたければ、BridgeノードやRouterノードを設ける

Software Bus - Context CFE_SB_SendMsg() Sending cFS App HK Requests Software Scheduler cFE Software Bus CFE_SB_RcvMsg() Receiving cFS App(s) cFS Training- Page 96

Software Bus Terms • Pipe – Destination to which SB Messages are sent; queues that can hold SB Messages until they are read out and processed • Message – A collection of data treated as a single entity. • Buffer – The generic piece of data moved on the Software Bus – Alignment is enforced at the buffer level – In general, applications receive buffers and cast them to a specific message type to use them cFS Training- Page 97

Software Bus and Message Module • cFS Caelum introduces a Message Module that encapsulates the definition of messages passed by cFE SB • cFE SB handles the routing of messages • cFE Message Module handles the definition and parsing of individual messages New in Caelum cFS Training- Page 98

Software Bus – Messages (1 of 2) • Messages are routed by a “MessageID” – This should always be treated as opaque – applications should not try to directly access the fields of a MessageID – By default, the Message Module provides two implementations (MISSION_MSG_V1 and MISSION_MSG_V2) • MISSION_MSG_V1 maps directly to the CCSDS Stream ID • CCSDS Primary Header (Always big endian) cFS Training- Page 99

Software Bus – Messages (2 of 2) • CCSDS Command Packets – Secondary packet header contains a command function code – cFS apps typically define a single command packet and use the function code to dispatch a command processing function – Commands can originate from the ground or from onboard applications • CCSDS Telemetry Packets – Secondary packet header contains a time stamp of when the data was produced – Telemetry is sent on the software bus by apps and can be ingested by other apps, stored onboard and sent to the ground cFS Training- Page 100

Software Bus – Message Formats • Message formats are defined in the Message Module, along with functions to access message header fields (CFE_MSG_GetApId, CFE_MSG_GetSequenceCount, etc.) union CFE_MSG_Message { CCSDS_SpacePacket_t CCSDS; uint8 Byte[sizeof(CCSDS_SpacePacket_t)]; } struct CFE_MSG_CommandHeader { CFE_MSG_Message_t Msg; CFE_MSG_CommandSecondaryHeader_t Sec; } struct CFE_MSG_TelemetryHeader { CFE_MSG_Message_t Msg; CFE_MSG_TelemetrySecondaryHeader_t Sec; uint8 Spare[4]; } cFS Training- Page 101

Software Bus – Reset Behavior • No data is preserved for either a Power-On or Processor Reset – All routing is reestablished as application create pipes and subscribe to messages – Any packet in transit at the time of the reset is discarded – All packet sequence counters reset to 1 cFS Training- Page 102

Software Bus – Retrieving Onboard State • Telemetry – Housekeeping Status • Counters (No subscribers, send errors, pipe overflows, etc.), Memory Stats • Telemetry packets generated by command – Statistics – Subscription Report • Files generated by command – Routing Info – Pipe Info – Message ID to Route cFS Training- Page 103

Software Bus - System Integration • • Message IDs should be unique across the system if possible The software bus places no restrictions on who can send or receive messages – One-to-one – One-to-many – Many-to-one – Many-to-many • The Software Bus Network application can be used to extend the software bus across multiple processors cFS Training- Page 104

CCSDS References • Consultative Committee for Space Data Systems • CCSDS Home: https://public.ccsds.org/default.aspx • CCSDS Space Packet Protocol: https://public.ccsds.org/Pubs/133x0b1s.pdf cFS Training- Page 120

• https://public.ccsds.org/default.aspx
• https://public.ccsds.org/Pubs/133x0b1s.pdf

• 2. cFE Services • a) Executive Services • b) Software Bus • c) Event Services • d) Time Services • e) Table Services 49 65 96 125 147 166

Event Services (EVS) - Overview • Provides an interface for sending time-stamped text messages on the software bus – Considered asynchronous because they are not part of telemetry periodically generated by an application – Processor unique identifier – Optionally logged to a local event log – Optionally output to a hardware port • Four event types defined – Debug, Informational, Error, Critical • Event message control – Apps can filter individual messages based on identifier – Enable/disable event types at the processor and application scope cFS Training- Page 124

• Event Services • cFSのEvent Services (EVS) は ROS 2のLogger(rclcpp::Logger) に相当するが、Logするだけではない。 • 機能で比較 比較項目 cFS: Event Services (EVS) ROS 2: Logging (rclcpp::Logger) 目的 アプリ内部の診断・エラーメッセージを通信 可能なイベントとして扱う ノード内部のログをstdoutやlogファイルに出力 出力先 ソフトウェアバス（SB）経由でテレメトリ 出力可。地上にも送信可能 ターミナル、rosout、ファイル（構成依存） フィルタ機能 帯域保護のため、イベントID単位での出力抑 制、型別（INFO/WARN/ERROR）など ログレベルでの制御（INFO/WARN/ERROR など） 出力logの永続性 プロセッサリセット後も保持されるローカル イベントログあり ログは基本RAMベース or ログローテーション任せ （永続性なし） 地上からの制御 コマンドでログ出力設定やリセットが可能 原則コード内制御 or 起動時引数で設定 宇宙機向け設計 高信頼設計、1Hzや通信量制限も考慮済 ミッションクリティカル前提ではない • EVS的機能をROS 2で再現するには • ログをテレメトリ化 rclcpp::Publisher<std_msgs::msg::String>でlog転送トピックを作成 • 出力制御 RCUTILS_LOGGING_SEVERITY 環境変数 or rclcpp::Loggerで制御 • ログ保存 ros2 bag record /log 等で収集 or systemd-journal連携 • 地上コマンド的制御 rclcpp::Parameter や service でフィルタON/OFF機能を実装可能

Event Services - Context Any cFS Application CFE_EVS_SendEvent Output Port Event Message cFE Event Services Event Message Local Event Log cFS Training- Page 125

Event Services – Message Format • Spacecraft time – Retrieved via CFE_TIME_GetTime() 14:14:40.500 ERROR CPU=CPU3 APPNAME=CFE_TBL EVENT ID=57 Unable to locate “TST_TBL.invalid_tbl_02 in Table Registry • Event Type – Debug, Informational, Error, Critical 14:14:40.500 ERROR CPU=CPU3 APPNAME=CFE_TBL EVENT ID=57 Unable to locate “TST_TBL.invalid_tbl_02 in Table Registry • Spacecraft ID (not shown) defined in cfe_mission_cfg.h • Processor ID defined in cfe_platform_cfg.h 14:14:40.500 ERROR CPU=CPU3 APPNAME=CFE_TBL EVENT ID=57 Unable to locate “TST_TBL.invalid_tbl_02 in Table Registry cFS Training- Page 126

Event Services – Message Format • Application – cFE Service or app name defined in cfe_es_startup.scr 14:14:40.500 ERROR CPU=CPU3 APPNAME=CFE_TBL EVENT ID=57 Unable to locate “TST_TBL.invalid_tbl_02 in Table Registry • Event ID is unique within an application 14:14:40.500 ERROR CPU=CPU3 APPNAME=CFE_TBL EVENT ID=57 Unable to locate “TST_TBL.invalid_tbl_02 in Table Registry • Event Text is created using printf() format options – “Short Format” platform option allows messages to be sent without text portion 14:14:40.500 ERROR CPU=CPU3 APPNAME=CFE_TBL EVENT ID=57 Unable to locate “TST_TBL.invalid_tbl_02 in Table Registry cFS Training- Page 127

Event Services – Event Filtering • Applications register events for filtering during initialization – Registering immediately after ES app registration allows events to be used rather than syslog writes • Bit-wise AND “filter mask” – Boolean AND performed on event ID message counter, if result is zero then the event is sent – Mask applied before the sent counter is incremented – 0x0000 => Every message sent – 0x0003 => Every 4th message sent – 0xFFFE => Only first two messages sent • CFE_EVS_MAX_FILTER_COUNT (cfe_evs_task.h) defines maximum count for a filtered event ID – Once reached event becomes locked – Prevents erratic filtering behavior with counter rollover – Ground can unlock filter by resetting or deleting the filter cFS Training- Page 128

Event Services - Ports • cFE supports up to 4 ports – Port behavior can be customized in cfe_evs_utils.c – By default, all ports call OS_printf • Event messages are sent to enabled ports in addition to the software bus • By default, enabled ports are defined with the configuration parameter: CFE_PLATFORM_EVS_PORT_DEFAULT – Enabled ports can be changed in runtime with the command CFE_EVS_EnablePortsCmd cFS Training- Page 129

Event Services – Message Control • Processor scope – Enable/disable event messages based on type • Debug, Information, Error, Critical • Application scope – Enable/disable all events – Enable/disable based on type • Event message scope – During initialization apps can register events for filtering for up to CFE_PLATFORM_EVS_MAX_EVENT_FILTERS defined in cfe_platform_cfg.h – Filters can be modified by command cFS Training- Page 130

Event Services – Reset Behavior • Power-on Reset – No data preserved – Application initialization routines register with the service – If configured local event log enabled • Processor Reset – If configured with an event log, preserves • Messages • Mode: Discard or Overwrite • Log Full and Overflow status cFS Training- Page 131

Event Services – Retrieving Onboard State • Housekeeping Telemetry – Log Enabled, Overflow, Full, Enabled – For each App: AppID, Events Sent Count, Enabled • Write application data to file. For each app – Active flag – Are events enabled – Event Count – For each filtered event • Event ID • Filter Mask • Event Count – Number of times Event ID has been issued • Local event log – – – – – If enabled, events are written to a local buffer Log “mode” can be set to overwrite or discard Serves as backup to onboard-recorder during initialization or error scenarios Suitable for multi-processor architectures Command to write log to file cFS Training- Page 132

• 2. cFE Services • a) Executive Services • b) Software Bus • c) Event Services • d) Time Services • e) Table Services 49 65 96 125 147 166

Time Services – Time Formats • Supports two formats • International Atomic Time (TAI) – Number of seconds and sub-seconds elapsed since the ground epoch – TAI = MET + STCF • Mission Elapsed Counter (MET) time since powering on the hardware containing the counter • Spacecraft Time Correlation Factor (STCF) set by ground ops • Note STCF can correlate MET to any time epoch so TAI is mandated • Coordinated Universal Time (UTC) – Synchronizes time with astronomical observations – UTC = TAI – Leap Seconds – Leap Seconds account for earth’s slowing rotation cFS Training- Page 147

• Time Services • cFSの Time Services は、ROS 2 の rclcpp::Clock /Time/clockトピック に対応。ただ、宇宙機仕様の時刻保証・ 分配機構はROS 2には存在しない。 • 比較： 観点 cFS TIME ROS 2 Clock 宇宙機向けの冗 長設計 外部トーン信号（地上局やGPS受信 機、親衛星など）外部装置から宇宙 機に送信される、1秒ごとの高精度な 時刻同期パルス信号）や冗長性 （flywheelモード）あり 1ソース前提、冗長性設計なし 1Hz Sync信号の アプリ実行タイミング同期に使える 分配 ROS 2にはそのような仕組みなし Leap Seconds 管理 地上コマンドで調整可能 基本未対応 リセット復元性 CDSで時刻保持・再開可能 通常再起動で初期化される プロセス間分配 SB経由で明示的に配信 各ノードがClock::now()呼び出し 冗長性 外部トーン、Flywheel対応など 外部補完ができるか。

Time Services - Context Time Requests Any cFS Application Time Data Software Scheduler HK Requests cFE Time Services Tone interrupt Tone Message Time 1Hz Tone Child Task Local Clock, 1Hz interrupt PSP 1Hz Wakeup Message Time 1Hz Child Task Local Timing Hardware Local/External Tone Source cFS Training- Page 148

Time Services – “Flywheeling” • Flywheeling occurs when TIME is not getting a valid tone signal or external "time at the tone" message. While this has minimal impact on internal operations, it can result in the drifting apart of times being stored by different spacecraft systems. • Flywheeling occurs when at least one of the following conditions is true: – loss of tone signal – loss of "time at the tone" data packet – signal and packet not within valid window – commanded into fly-wheel mode cFS Training- Page 149

Time Services – Reset Behavior • Power-On-Reset – Initializes all counters in housekeeping telemetry – Validity state set to Invalid – STCF, Leap Seconds, and 1 Hz Adjustment set to zero • Processor reset, preserves: – MET – STCF – Leap Seconds – Clock Signal Selection – Current Time Client Delay (if applicable) – Uses ‘signature’ to determine validity of saved time. If signature fails then poweron-reset initialization is performed cFS Training- Page 150

Time Services – Retrieving Onboard State • Telemetry – Housekeeping Status • Clock state, Leap Seconds, MET, STCF 1Hz Adjust • Telemetry packets generated by command – Diagnostic Packet • Files generated by command – None cFS Training- Page 151

Time Services – Configuration Considerations • What is your time format? • Are you setting time or receiving time? • Is your MET provided by local hardware? • Is time coming from an external source? • How long can you go without synchronizing time? cFS Training- Page 152

• 2. cFE Services • a) Executive Services • b) Software Bus • c) Event Services • d) Time Services • e) Table Services 49 65 96 125 147 166

Table Services (TBL) - Overview • What is a table? – Tables are logical groups of parameters that are managed as a named entity • Parameters typically change the behavior of a FSW algorithm – Examples include controller gains, conversion factors, and filter algorithm parameters • Tables service provides ground commands to load a table from a file and dump a table to a file – Table loads are synchronized with applications • Tables are binary files – Ground support tools are required to create and display table contents • The cFE can be built without table support – Note the cFE services don’t use tables cFS Training- Page 165

• Table Services • cFSの Table Services はROS 2のrclcpp::Parameterに相当 • 機能比較： 設計観点 cFS Table Services ROS 2 Parameters 安全性 二段階更新＋検証あり 即時更新でアプリ側実装次第 運用性 リモート更新・差分転送・CDS保持 まで含む シンプルな一時構成、原則ローカル 共有性 複数アプリ間で同一テーブル利用可 ノード間で明示的共有はなし 初期化方法 ファイル・コマンド・アプリから定 義可能 YAML or declare_parameter() 宇宙運用時 シナリオ中の変更、失敗時ロール バックなど 必要に応じて外部実装が必要 冗長性 外部トーン、Flywheel対応など 外部補完ができるか。 • ROS 2でcFS Servicesを実現するには • テーブル構造定義 nav2_params.yaml のような構造YAML or 独自msg型 • テーブルの更新 ROS 2サービス or Action経由で受け取るノード設計 • 検証機能 パラメータコールバックでチェックロジック記述 • 自動反映 rclcpp::ParameterEventCallback + ファイル監視機能 • CDS的保持 永続化ファイルを設けて、次回起動時に読み込み

Table Services – Managing Tables Inactive Buffer File Load Poll Table Maintenance Function (Typically run on HK cycle) Table Service Dump Get Pointer Run Loop Processing Active Buffer • Active Table - Image accessed by app while it executes • Inactive Table - Image manipulated by ops (could be stored commands) • Load → Validate → Activate • – Loads can be partial or complete – For partial loads current active contents copied to inactive buffer prior to updates from file – Apps can supply a “validate function” that is executed when commanded Dump – Command specifies whether to dump the active or inactive buffer to a file • Table operations are synchronous with the application that owns the table to ensure table data integrity • Non-Blocking table updates allow tables to be used in Interrupt Service Routines cFS Training- Page 166

Table Services - Load Table Transfer File to Flight Load Table App Activate Table Validate Contents1 Activate Table1,2 TBL Service CFDP cFS Validate Table File Ground xfer File Cmd Active Table Buffer Inactive Table Buffer Table Load Cmd Validate Table Cmd Activate Table Cmd Time 1. Apps typically validate & activate tables during their “housekeeping” execution cycle 2. In addition to instructing cFE to copy the contents, apps may have app-specific processing cFS Training- Page 167

Table Services - Dump Table Dump Table Transfer File to Ground App cFS Ground TBL Service CFDP Active or Inactive Table Buffer File Table Dump Cmd xfer File Cmd Time cFS Training- Page 168

Table Services –Table Buffer Types • Single Buffer – The active buffer is the only buffer dedicated to the application’s table – Table service shares inactive buffers to service multiple app’s with single buffer tables • CFE_TBL_MAX_SIMULTANEOUS_LOADS defines the number of concurrent table load sessions – Most efficient use of memory and adequate for most situations – Since #define CFE_TBL_OPT_DEFAULT (CFE_TBL_OPT_SNGL_BUFFER | CFE_TBL_OPT_LOAD_DUMP) • Double Buffer – Dedicated inactive image for each double buffered table – Useful for fast table image swaps (.e.g. high rate app and/or very large table) and delayed activation of table’s content (e.g. ephemeris) – E.g. Stored Command’s Absolute Time Command table • Shared single buffer pool must be sized to accommodate the largest single buffer image cFS Training- Page 169

Table Services –Table Attributes • Validation Function – Applications register validation functions during initialization – Table activates for tables with validation functions will be rejected if the validation has not been performed – Mission critical data table values are usually verified • Critical Tables – Table data is stored in a Critical Data Store (CDS) – Contents updated for each table active command • User Defined Address – Application provides the memory address for the active table buffer – Typically used in combination with a dump-only table • Dump-Only – Contents can’t be changed via the load/validate/activate sequence – The dump is controlled by the application that owns the table so it can synchronize the dump and avoid dumps that contain partial updates cFS Training- Page 170

• 1. Introduction • 2. cFE Services • a) Executive Services • b) Software Bus • c) Event Services • d) Time Services • e) Table Services • 3. Application Layer • a) cFS Applications • b) cFS Libraries • Application Build Context • Application Runtime Context • Existing Application • Application Design 5 49 65 96 125 147 166 188 191 192 193 198 202 214 214

• 3. Application Layer • a) cFS Applications • b) cFS Libraries • Application Build Context • Application Runtime Context • Existing Application • Application Design 188 191 192 193 198 202 214