Space ROS aims to provide ROS software, including the core libraries and tools, that is usable in space-based assets, not just the ground component of missions. To this end, it must provide high quality software and related assets that can satisfy a certification or validation process such as that used by Nasa or the ESA. Part of this is having in place a requirements process and tools to support it.

Regenerate the Space ROS repos file using rosinstall_generator to make sure that we're up-to-date.

ECCS-E-ST-40C is the European Cooperation for Space Standardization's standard for software. This is the standard that ESA and companies such as Airbus work toward.

We should try to comply with this standard where feasible and not conflicting with NASA/DO-178C requirements, as it will make it easier for European aerospace organisations to get involved in and use Space ROS.

Prototype the Events and Telemetry System in order to better understand its requirements

migrate from https://github.com/osrf/sa-spaceros/issues/7 (originally by @mjeronimo)

clang-tidy complains about several occurrences of C++ constructors that could potentially be specified as 'explicit.' For example,

"'operator Duration_' must be marked explicit to avoid unintentional implicit conversions [google-explicit-constructor]"

However, often there can be good reason for them not being explict. We should evaluate each occurrence of the "google-explicit-contructor" warning in the Space ROS code (vnv list) and update the code accordingly or identify the occurrence as a false posititive.

migrated from https://github.com/osrf/sa-spaceros/issues/9 (originally by @mjeronimo)

clang-tidy complains about several occurrences of default arguments (google-default-arguments) used on virtual or override methods, which are prohibited according to the "google-default-arguments" check. We should evaluate each occurrence of the warning in the Space ROS code vnv-list and update the code accordingly or identify the occurrence as a false posititive.

In the Dockerfile for Space ROS, the script is currently manually generating the .egg file from the egg-info directory. I would be better to fix this in the upstream repo and then update the Docker script accordingly.

Here is the issue in the IKOS repo: NASA-SW-VnV/ikos#185

• Update the links to news and presentations
  • Ama’s Flight Software presentation
  • https://www.therobotreport.com/open-robotics-developing-space-ros/
  • Motiv press release
• Include attribution for images
• Update contact email address ([email protected])
• Any other minor content updates

Update the README for the Space ROS docker_images repo to describe how to generate and view the consolidated output.

Space ROS is going to accumulate many processes, beginning with a requirements process. We need a tool that will allow us to:

• Record these processes
• Track how they change over time
• Trace to the version of a process that was followed for a specific instance of a task, e.g. a code review

Enable the AutoSAR checks (only) with SARIF output.

DO-178C is the central standard for avionics software that the American aerospace community uses. It likely has much useful information on how we should develop Space ROS and what artefacts we need to provide to Space ROS users.

In order to help us catalogue and address (whether that be by making sure its allocator can be overridden properly or by eliminating it for upstream ROS 2 or just Space ROS) all the sources of memory allocation in those two demos, we need to enumerate them first.

Use things like https://github.com/osrf/osrf_testing_tools_cpp#memory_tools to find all allocations and perhaps categorize them so we can reason about what needs to be done for each.

Definition of Done for this task is a list of all memory allocations for the talker and listener applications (C++) in the demo_nodes_cpp package, with optional categorization as it makes sense.

We'll use gcc and Ubuntu Linux 20.04 (maybe 22.04 @nuclearsandwich?) as that may affect what the std library will do based on its version.

Also, we could look at the call trace and check the API docs of all the system calls and std library calls made to ensure they shouldn't allocate memory in corner cases either.

Update ament_clang_tidy to generate SARIF output.

migrated from https://github.com/osrf/sa-spaceros/issues/6 (originally by @mjeronimo)

Clang-tidy detects the usage of several potentially insecure functions:

"Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]"
"Call to function 'snprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'snprintf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]"
"Call to function 'strncat' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'strncat_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]"
"Call to function 'strncpy' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'strncpy_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]"
"Call to function 'vsnprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'vsnprintf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]"

We should address these occurrences (clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling) in the Space ROS vnv list of packages. We can potentially us the rcutils versions of the functions.

In addition to the JUnit XML output, each of the tools should also output a SARIF file. The SARIF files will be used as input to the Space ROS dashboard.

migrated from https://github.com/osrf/sa-spaceros/issues/12 (originally by @mjeronimo)

clang-tidy identifies several occurrences of "google-runtime-references" where there is a non-const reference parameter and suggests to make it const or use a pointer. These occurrences in the Space ROS code (vnv list) should be evaluated and updated or identified as false positives.

Currently, IKOS outputs JUnit XML for individual binaries in a build. However, we want these to be consolidated into a single report for each package (similar to other static analysis tools).

migrated from https://github.com/osrf/sa-spaceros/issues/13 (originally by @mjeronimo)

clang-tidy identifies several occurrences of "clang-analyzer-valist.Uninitialized" where, it claims, an uninitialized va_list is copied. These occurrences should be evaluated in the Space ROS code (vnv list) and fixed or identified as false positives.

• #13

IKOS natively generates SARIF output for individual executables. However, when running a scan on a project, there may be multiple executables and therefore multiple output SARIF files. These files need to be consolidated into a single output file for the project.

Update code to conform to linters and static analyzers.

• #8
• #9

Occasionally, updates to external repositories cause the Docker builds to break. Update the Dockerfiles for MoveIt2 and MoveIt2 Tutorials so that they build correctly.

migrated from https://github.com/osrf/sa-spaceros/issues/10 (originally by @mjeronimo)

clang-tidy complains about rcl_parse_arguments exceeding recommended size/complexity:

"function 'rcl_parse_arguments' exceeds recommended size/complexity thresholds [google-readability-function-size]"

We should evaluate whether this function can be refactored to improve the length/clarity.

Upstream ROS 2 has disabled cppcheck >= 2.0 by default due to severe performance degradation with the way it is invoked by ament_cppcheck (ament/ament_lint#345).

Before doing extra work to try and resolve the performance issues to preserve ament_cppcheck use for Space ROS, we should look at the checks cppcheck performs and determine how many are covered by our use of clang static analysis via clang-tidy, cpplint, and the rest of the ament_lint_common stack.

Once we have a comparison, we can propose either dropping cppcheck or investing time into investigating its performance issues.

Problem is described and resolved in ament/ament_lint#400. Documenting here as well since it is a problem that will impact SARIF processing, specifically determining if results across multiple static analyzers are pointing to the same file/line.

The CSS needs to be updated to layout correctly on phones and tablets.

Update the ament_cobra tool to use Cobra's json_convert tool to generate SARIF output.

Currently, IKOS outputs SARIF output for individual binaries in a build. However, we want these to be consolidated into a single report for each package (similar to other static analysis tools).

Occasionally, updates to external repositories cause the Docker builds to break. Update the Dockerfiles for Space ROSso that they it builds correctly.

To create the input for the local dashboard (which will be use Mozaik), consolidate the separate SARIF files generated from the static analyzers into a single SARIF file.

The script to do the consolidation can be done in Python and integrated into a post-build step so that the single SARIF file is ready for ingestion by the dashboard display code.

Now that the initial branches for Humble are online we can update the upstream branches for Space ROS to match Humble instead of Rolling.

Fixed several issues in the upstream Cobra repository: nimble-code/Cobra#48

Once this is integrated, ament_cobra will be able to generate SARIF output using the tool and IDE plug-ins will be able to read the SARIF files.

Check the output of all SARIF-generating ament tools against a SARIF validation tool, such as https://sarifweb.azurewebsites.net/Validation

Space ROS CI builds have been initially configured on Ubuntu Focal but Ubuntu Jammy is the primary target platform.

Build configuration issues have also arisen for the Space ROS and IKOS builds which need to be addressed.

FRET is a tool developed by NASA for the production of formally-verifiable requirements. There is great interest in using it for Space ROS due to its ability to check that requirements are correct - something that is useful when non-requirements-experts are going to be producing requirements.

We need to learn how to use it and perform an evaluation of its usefulness.

We need to determine if it is suitable for all of our requirements needs, or should be used in conjunction with another tool such as Doorstop. If it needs to be used in conjunction with another tool, then we need to figure out how to integrate the tools.

• Use the ruby gem tool, html-proofer
• Integrate and test the 'non-blog-content' branch
• Fix the relative link processing for the bg-photo items
• Add some code for separate video windows and adjust to a carousel at the cross-over point

• #8
• #9
• #2

• Move the website to the Space ROS github organization
• Do the proper github hosting (separate, non-content branch)
• Update DNS, CNAME processing to make the site available on space.ros.org

There is currently a work-around introduced (e8cbe31) to avoid an issue with the launch repo (ros2/launch#588). This issue is a reminder to revert this change once the upstream bug is fixed.

migrated from https://github.com/osrf/sa-spaceros/issues/8 (originally by @mjeronimo)

clang-tidy identifies several occurrences of bypassing virtual dispatch during object construction and destruction. For example,

"<symbol>” during construction bypasses virtual dispatch [clang-analyzer-optin.cplusplus.VirtualCall]"
"<symbol>” during destruction bypasses virtual dispatch [clang-analyzer-optin.cplusplus.VirtualCall]"

We should evaluate these occurrences in the Space ROS source code (vnv list) to fix or identify as a false positive.

If I'm not mistaken (which is quite possible, new to ROS2), the only tests run for a package under colcon test are ones that are listed in that package's package.xml within <test_depend>package_name</test_depend> tags. Some ROS2 packages (take rcutils for example) test_depend on ament_lint_common, which in turn depend on all of our static analyzers (ament_clang_tidy, ament_copyright, ament_cobra, ament_cppcheck, etc). However, other packages (take tf2 for example) only depend on a subset of these analyzers, so they are not all run.

I'm not sure what the best way to resolve this is. There are two things I can think of:

1. If the only place to indicate test dependencies is in a packages package.xml (which I believe is the case, but again could be wrong), insert <test_depend> tags during docker build, or when another common command is triggered (colcon build, colcon test, entrypoint.sh for the docker image, or maybe an explicit command run by the user).
2. Upstream the <test_depend> to all of the ROS packages we want to run our static analysis tools on, either to the main ROS2 branches, or to spaceros branches.

Option 1 feels wrong to me, and option 2 feels overbearing.

• #15
• #26
• #27
• #28

• #13
• #17
• #18
• #19
• #20
• #21
• #22

• Generate instructions for PCLP2.0 installation
• Run PCLP2.0 with the AutoSAR C++14 ruleset
• Integrate PCLP 2.0 into Ament_lint to run AutoSAR C++ 14
• Run ament_pclint into core packages for SpaceRos
• Generate a summary report of the issues found.
• Generate Sarif output from PCLP2.0