diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json index 6c4c4b1..782edd1 100644 --- a/.obsidian/workspace.json +++ b/.obsidian/workspace.json @@ -20,30 +20,6 @@ "icon": "lucide-file", "title": "ccsdspackets" } - }, - { - "id": "c8ca0d77ae25eb55", - "type": "leaf", - "state": { - "type": "image", - "state": { - "file": "flatsat/images/TMdfs.png" - }, - "icon": "lucide-image", - "title": "TMdfs" - } - }, - { - "id": "c9cf286edb13018b", - "type": "leaf", - "state": { - "type": "image", - "state": { - "file": "flatsat/images/TMsh.png" - }, - "icon": "lucide-image", - "title": "TMsh" - } } ] } @@ -195,16 +171,24 @@ "templates:Insérer le modèle": false, "command-palette:Ouvrir la palette de commandes": false, "templater-obsidian:Templater": false, - "obsidian-excalidraw-plugin:Create new drawing": false, "table-editor-obsidian:Advanced Tables Toolbar": false, "obsidian-git:Open Git source control": false, - "obsidian-kanban:Create new board": false + "obsidian-kanban:Create new board": false, + "obsidian-excalidraw-plugin:Create new drawing": false } }, "active": "bdbe27e596921cb8", "lastOpenFiles": [ + "flatsat/images/TMdfs.png", + "flatsat/images/pustc.png", + "flatsat/images/pustm.png", + "flatsat/pus.md", "flatsat/can.qmd", + "flatsat/images/puframe.png", "flatsat/ccsdspackets.qmd", + "flatsat/flatsat.qmd", + "flatsat/endurance.qmd", + "flatsat/images/TMsh.png", "index.qmd", "LearningMore/swdev.qmd", "LearningMore/images/release.png", @@ -212,18 +196,10 @@ "LearningMore/images/Capture d’écran du 2024-11-15 11-35-46.png", "LearningMore/images/basic.png", "LearningMore/images/hotfix.png", - "LearningMore/images/Capture d’écran du 2024-11-15 11-29-57.png", - "LearningMore/images/Capture d’écran du 2024-11-15 11-30-50.png", - "LearningMore/images/Capture d’écran du 2024-11-15 11-31-01.png", "flatsat/yamcs.qmd", "LearningMore/yamcsbasesetup.qmd", "_site/search.json", "_site/robots.txt", - "_site/sitemap.xml", - "_site/flatsat/images/yamcs.png", - "_site/flatsat/images/unsolicitedTM.png", - "_site/flatsat/images", - "_site/LearningMore/images", "LearningMore/yamcsbasesetup.md", "().md", "flatsat/yamcs.md", diff --git a/_quarto.yml b/_quarto.yml index 543b059..26ba2a3 100644 --- a/_quarto.yml +++ b/_quarto.yml @@ -1,23 +1,23 @@ -project: +project: type: website - -website: + +website: page-navigation: true - title: "FlatSat Introduction Presentation" - site-url: "https://rlhoussaine.github.io/FlatSatIntro/" - - repo-url: https://github.com/rlhoussaine/FlatSatIntro + title: "FlatSat Introduction Presentation" + site-url: "https://rlhoussaine.github.io/FlatSatIntro/" + + repo-url: https://github.com/rlhoussaine/FlatSatIntro repo-actions: [edit, issue] - + page-footer: right: "This page is built with ❤️ and [Quarto](https://quarto.org/)." left: "© CC-By Openscapes, 2024" - + sidebar: logo: "images/bsvg.png" pinned: true align: center - tools: + tools: - icon: globe href: https://www.infiniteorbits.io/ text: "infiniteorbits.io" @@ -26,7 +26,7 @@ website: text: "Infinite Orbits github" - icon: instagram href: https://www.instagram.com/infinite_orbits/?hl=en - text: "IO Instagram" + text: "IO Instagram" style: "docked" search: true @@ -36,7 +36,7 @@ website: text: Welcome - section: "Flatsat" contents: - - href: flatsat/endurance.qmd + - href: flatsat/endurance.qmd text: Endurance overview - href: flatsat/flatsat.qmd @@ -48,6 +48,9 @@ website: - href: flatsat/ccsdspackets.qmd text: Space packets + - href: flatsat/pus.qmd + text: Pus services + - href: flatsat/yamcs.qmd text: yamcs interface and Endurance flatsat library @@ -81,5 +84,3 @@ format: filters: - include-files.lua - quarto - - diff --git a/flatsat/ccsdspackets.qmd b/flatsat/ccsdspackets.qmd index d562daf..3787bb8 100644 --- a/flatsat/ccsdspackets.qmd +++ b/flatsat/ccsdspackets.qmd @@ -34,6 +34,7 @@ following sequence: The Packet Primary Header is mandatory and shall consist of four fields, positioned contiguously, in the following sequence: + - Packet Version Number (3 bits, mandatory); - Packet Identification Field (13 bits, mandatory); - Packet Sequence Control Field (16 bits, mandatory); @@ -54,6 +55,7 @@ contiguously, in the following sequence: ## TC transfert frame A TC Transfer Frame shall encompass the major fields, positioned contiguously, in the following sequence: + 1. Transfer Frame Header (5 octets, mandatory); 2. Transfer Frame Data Field (up to 1019 or 1017 octets, mandatory); 3. Frame Error Control Field (2 octets, optional). @@ -157,4 +159,4 @@ octets as follows: ## Conclusion Both CAN-TS and CANopen have crucial roles in embedded systems, each suited for specific applications: CAN-TS for memory-limited aerospace applications, CANopen for complex industrial systems. ---- +--- \ No newline at end of file diff --git a/flatsat/images/puframe.png b/flatsat/images/puframe.png new file mode 100644 index 0000000..d39649e Binary files /dev/null and b/flatsat/images/puframe.png differ diff --git a/flatsat/images/pustc.png b/flatsat/images/pustc.png new file mode 100644 index 0000000..7c6b649 Binary files /dev/null and b/flatsat/images/pustc.png differ diff --git a/flatsat/images/pustm.png b/flatsat/images/pustm.png new file mode 100644 index 0000000..c154689 Binary files /dev/null and b/flatsat/images/pustm.png differ diff --git a/flatsat/pus.qmd b/flatsat/pus.qmd new file mode 100644 index 0000000..b9e05c5 --- /dev/null +++ b/flatsat/pus.qmd @@ -0,0 +1,181 @@ + +PUS Service +## Space Packet Structure + + +![](images/puframe.png) + +### Packet Version Number +- Set to **0**, identifying it as a space packet (version 1 CCSDS packet). + +### Packet Type Bit +- **0**: Telemetry packets. +- **1**: Telecommand packets. + +### Secondary Header Flag +- Indicates the **presence or absence** of a secondary header: + - **Telemetry packets**: All include a secondary header, except spacecraft time packets. + - **Telecommand packets**: All include a secondary header, except CPDU command packets. + +### Application Process ID (APID) +- **Uniquely identifies**: + - The source of telemetry packets. + - The destination of telecommand packets. +- Some values are reserved by CCSDS and unavailable for PUS services. + +### Sequence Flags +- Unused by the protocol but set to **"11"** to indicate stand-alone packets. +- All packets in this Standard are **stand-alone packets**. + +### Packet Sequence Count +- **Telemetry packets**: Incremented by 1 for each released packet and wraps at \(2^{14} - 1\). +- **Telecommand packets**: Use a sequence count or packet name to uniquely identify packets within a communication session. + +### Packet Data Length Field +- Specifies the length of the **packet data field**: + - Value is **one less** than the number of octets in the data field. + - Total packet length = Packet data field length + 6 octets (primary header). + +### Packet Data Field Structure +- **Telemetry Packets**: + - Secondary header. + - User data field. +- **Telecommand Packets**: + - Secondary header. + - User data field. + +- - - +### Telemetry Packet Data Field + +#### Telemetry Packet Secondary Header + + +![](images/pustm.png) + +1. **Presence**: + - All telemetry packets, except spacecraft time packets, include a secondary header. + +2. **Structure**: + - **Fields**: + - **Spacecraft Time**: Absolute, fixed-size. + - **PUS Version**: 4 bits, set to **2**. + - **Reference Number**: 4 bits, enumerated. + - **Message Type ID**: 8 bits, enumerated. + - **Service Type ID**: 8 bits, enumerated. + - **Message Subtype ID**: 8 bits, enumerated. + - **Message Counter**: 16 bits, unsigned integer. + - **Destination ID**: Application process user identifier. + - **Spare Field**: Optional, used to align header size to integral words. + +3. **Time Reference**: + - **Status**: + - If capable, set to the status of the onboard time reference when tagging packets. + - If not capable, set to **0**. + - **Time Tag**: Stored in the time field of the header. + +4. **Message Metadata**: + - **Type ID**: Set to the identifier of the report. + - **Counter**: + - If capable, set to the count of messages of this type. + - If not capable, set to **0**. + +5. **Declaration Requirements**: + - Presence and bit-size of the spare field must be declared for each application process. + - Time field PFC (Packet Format Control) must align with the spacecraft's time service. + +#### Notes: +- The **PUS Version** indicates compliance with ECSS-E-ST-70-41C (version 2). +- The **Spare Field** adjusts header length and is application-specific. + + +- - - +### Telecommand Packet Data Field + +#### Telecommand Packet Secondary Header + + +![](images/pustc.png) + +1. **Presence**: + - All telecommand packets include a secondary header, except for CPDU command packets. + +2. **Structure**: + - **Fields**: + - **Acknowledgement Flags**: 4 bits, controls reporting of request states: + - Bit 3: Successful acceptance by the destination application process. + - Bit 2: Successful start of execution by the destination application process. + - Bit 1: Progress reporting of execution. + - Bit 0: Successful completion of execution. + - **PUS Version**: 4 bits, set to **2**. + - **Message Type ID**: 8 bits, enumerated. + - **Service Type ID**: 8 bits, enumerated. + - **Message Subtype ID**: 8 bits, enumerated. + - **Source ID**: 16 bits, identifies the source application process. + - **Spare Field**: Optional, aligns header size to integral words. + +3. **Request Metadata**: + - **Message Type ID**: Set to the identifier of the request. + - **Source ID**: Set to the source identifier of the issuing application process. + +4. **Declaration Requirements**: + - Presence and bit-size of the spare field must be declared for each application process. + +#### Notes: +- The **PUS Version** reflects compliance with ECSS-E-ST-70-41C (version 2). +- Acknowledgement flags provide flexibility in managing state reporting for telecommand requests. +- The **Spare Field** ensures compatibility with system-specific requirements. + +- - - + +## Comprehensive Overview of the Packet Utilization Standard (PUS) + +### Introduction +The **Packet Utilization Standard (PUS)**, part of the ECSS standards, defines a framework for using telemetry and telecommand packets to monitor and control spacecraft subsystems and payloads. Initially developed by ESA in the 1990s, PUS has become a widely adopted standard for spacecraft operations, reducing mission complexity and enhancing interoperability. + +### Purpose +PUS establishes a unified structure for spacecraft communication, enabling: +- **Remote Monitoring**: Observing spacecraft status and health. +- **Command Execution**: Controlling onboard systems and payloads. +- **Operational Consistency**: Standardizing processes across missions. + +### Key Features +- **Modular Services**: Provides predefined services for common spacecraft operations. +- **Tailorability**: Allows customization for mission-specific needs. +- **Interoperability**: Facilitates seamless interaction between ground stations and spacecraft. + +### Standardized Services +PUS defines various services, each targeting a specific operational aspect. Below is a list of core services: + +| No. | Service Name | +|-----|----------------------------------------------| +| 1 | Telecommand Verification | +| 2 | Device Command Distribution | +| 3 | Housekeeping and Diagnostic Data Reporting | +| 4 | Parameter Statistics Reporting | +| 5 | Event Reporting | +| 6 | Memory Management | +| 8 | Function Management | +| 9 | Time Management | +| 11 | On-board Operations Scheduling | +| 12 | On-board Monitoring | +| 13 | Large Data Transfer | +| 14 | Packet Forwarding Control | +| 15 | On-board Storage and Retrieval | +| 17 | Test | +| 18 | On-board Operations Procedure | +| 19 | Event-Action | + +### Benefits +1. **Reduced Complexity**: By standardizing telemetry and telecommand operations, PUS simplifies spacecraft design and development. +2. **Flexibility**: Missions can select and implement only the services they require. +3. **Reliability**: Standardized procedures enhance robustness and minimize operational errors. + +### Tailoring for Missions +Each mission can adapt PUS to its unique requirements by selecting relevant services, adjusting parameters, and defining custom extensions when necessary. The process involves: +- Assigning specific Application Process Identifiers (APIDs). +- Configuring service capabilities, such as memory management areas or telemetry event thresholds. +- Documenting these decisions in a Space-to-Ground Interface Control Document (ICD). + +### Applications +PUS is a cornerstone of ESA missions, including Rosetta, Envisat, and Integral. It is also suitable for missions with diverse architectures, from centralized systems to distributed networks onboard spacecraft. +