nasa / cfs Goto Github PK

I cloned this cFS repository with all its submodules, followed the instructions in the README for compilation. I get the following error when running the executable (core-cpu1).

CFE_PSP: Default Reset Type = PO
CFE_PSP: Default Reset SubType = 1
CFE_PSP: Default CPU ID = 1
CFE_PSP: Default Spacecraft ID = 42
CFE_PSP: Default CPU Name: cpu1
CFE_PSP: Starting the cFE with a POWER ON reset.
CFE_PSP: OS_API_Init() failure

I am working on a linux workstation running ubuntu 18.04. Any insight would be helpful.

Having to build and open the documentation locally adds an extra step that could be mitigated by pushing the documentation of the current master commit to GitHub pages.

The process of uploading to GitHub pages is documented here

Is your feature request related to a problem? Please describe.
Skeleton app added, missing reference in readme

Describe the solution you'd like
Add reference

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

There was an issue using cmake to perform any type of build operation (clean, prep, make, etc), it kept reporting that there was something wrong with gcc. The issue was that the following was missing from /cfe/CMakeLists.txt:

INCLUDE(CMakeForceCompiler)
CMAKE_FORCE_C_COMPILER(gcc GNU)
CMAKE_FORCE_CXX_COMPILER(g++ GNU)

Including these lines at the top of file fixed my issue. I am running CentOS 2.6.32-754.17.1.el6.x86_64

Is your feature request related to a problem? Please describe.
sample_lib triggers a lgtm error based on checking strncpy return (false alarm)

Describe the solution you'd like
Exclude string-copy-return-value-as-boolean (triggered by sample_lib, which is doing this on purpose)

Describe alternatives you've considered
Could clutter code to exclude this specific call from triggering the warning.

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

Is your feature request related to a problem? Please describe.
Update lgtm.yml file to include python

Requester Info
Anh Van, NASA Goddard

Is your feature request related to a problem? Please describe.
Travis CI currently just does cppcheck and default build on the bundle

Describe the solution you'd like
Parallel test the following:

• BUILDTYPE=release OMIT_DEPRECATED=true STRICT_NO_WARNINGS=true
• BUILDTYPE=release OMIT_DEPRECATED=false(default) STRICT_NO_WARNINGS=true
• BUILDTYPE=debug(default) OMIT_DEPRECATED=true STRICT_NO_WARNINGS=true
• BUILDTYPE=debug(default) OMIT_DEPRECATED=false(default) STRICT_NO_WARNINGS=true

And do the following tests:

• Add document generation (eventually enforce no warnings)
  • make doc
  • make usersguide
  • make osalguide (dependent on nasa/cFE#446)
• Build with ENABLE_UNIT_TESTS=TRUE SIMULATION=native
• Run unit tests (eventually enforce coverage)
• Execute cFE and pipe output to file
• Send reset cmd from cmdutil
• Confirm execution output lacks error/warning/fail messages

Describe alternatives you've considered
None

Additional context
Eventually add nightly or triggered local builds for other environments (pc-RTEMS, vxworks on a modern platform)
Eventually add automated build verification (trade CI vs local)

Requester Info
Jacob Hageman - NASA/GSFC

Is your feature request related to a problem? Please describe.
Deprecated elements included in analysis

Describe the solution you'd like
Remove deprecated elements from analysis

Describe alternatives you've considered
None.

Additional context
Will address some of the open LGTM issues.

Requester Info
Jacob Hageman - NASA/GSFC

Is your feature request related to a problem? Please describe.
Certification configuration is CCSDS extended header, 32bit. Default config is currently CCSDS primary only, 64 bit.

Describe the solution you'd like
CI with cFS header definition V2, and any other minor tweaks for cert config.

Describe alternatives you've considered
Leaning towards adding a V2 config that maps to the cert configuration to CI
Won't be the full CI until related issues get resolved.

Additional context
Will need to resolve any related V2 issues (cmdUtil doesn't support it, etc), issues in implicit packet padding differences, etc.

Requester Info
Jacob Hageman - NASA/GSFC

Is your feature request related to a problem? Please describe.
CI in #39 only checks for warn/err/fail in cFS output

Describe the solution you'd like
Enforce the existence of the following message:
"CFE_ES_Main entering OPERATIONAL state"

Describe alternatives you've considered
Any other positive check would work, above was the simplest I could think of.

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

Hi,

I cannot find the gen_app_code tool, although it is mentioned in the official CFS-101. How can I effectively create an app now?

Regards,
Nick

Is your feature request related to a problem? Please describe.
Inconsistent style used throughout cFS

Describe the solution you'd like
Automated way to apply style that can be enforced by CI if desired

Describe alternatives you've considered
None

Additional context
N/A

Requester Info
Jacob Hageman - NASA/GSFC

My app, named CNT_APP starts running and while there are tables in the app, it appears that CFE_TBL attempts to load those tables and fails, causing CNT_APP to error out. Is there a missing step that I need to perform (load tables?) or is this indicative of a bug or misconfiguration?

When attempting to dump a table the format for the python GroundSystem is unclear.

My attempt syntax is as follows. It appears to concatenate the table and the table file name, making it hard to discern any proper convention for the arguments of the command.

Is your feature request related to a problem? Please describe.
It would be helpful to know exactly what versions of everything Travis is doing a CI against.

Describe the solution you'd like
Adding "git submodule" and "git rev-parse HEAD" to the Travis script.

Requester Info
[email protected]

Is your feature request related to a problem? Please describe.

add lgtm badge to readme

Requester Info
Anh Van, NASA Goddard

Describe the bug
Unable to quickly find the Contributor License Agreement (CLA). Recommend adding to README of each repository.

Reporter Info
John P. Lucas - NASA GSFC

Is your feature request related to a problem? Please describe.
Add lgtm.yml file.

Requester Info
Anh Van, NASA Goddard

I've started working on Markdown-izing documentation on my fork of this repository so it's easier to navigate via GitHub's interface. I plan to convert all plain-text, PDF, and Word documents to Markdown, but leave Doxygen docs intact since they're generated (However, on that subject, on the CACTUS fork of cFE I made a Travis job that automatically builds Doxygen docs and deploys them to GitHub Pages).
I can open a PR here once the conversion is complete if the cFE team would like to integrate that change in the main repo.

Since the release of cFE 6.6, there hasn't been apps that give an example of the way tests should be defined in the CMakeLists file. Previously, when UTAssert was part of the tools directory rather than being part of the OSAL, this definition would exist inside of the fsw/for_build/Makefile but this doesn't cleanly translate to cFE 6.6's cmake build system.

The arch_build.cmake file located in the cmake directory seems to have a function add_unit_test_exe but I couldn't get this to work when calling it from the simple app's CMakeList.txt. An explanation of what needs to be done in either the target.cmake or CMakeLists file for an app or an example of an app using UT for it's testing would be appreciated.

I get the following message when I try to publish a message on the software bus from within a call back function that is called by a timer.

CFE_ES_GetTaskInfo: Task ID Not Valid: 0

Steps to reproduce the behavior:
sample_app.txt

• Download the attached sample_app.txt
• Rename .txt to .c
• Replace apps/sample_app/fsw/src/sample_app.c with the renamed sample_app.c file
• compile and run core-cpu1.

** code info **
Please note that the time call back function in the attached sample_app is at the very end of the file. The timer is initialized within the app's initialization function.

System observed on:

• x86_64
• OS: [e.g. Linux 4.15]
• Versions [cFS repository at commit hash: 044476b (current master branch as on 11/14)]

Reporter Info
NASA Langley/NIA

Any thoughts on how to resolve this is greatly appreciated.

Is your feature request related to a problem? Please describe.
gen_msgids has not been maintained and a current user hasn't been identified. Modern projects utilize other toolchains/schemes for managing ApIDs.

Describe the solution you'd like
Remove gen_msgids from the cFS Framework bundle.

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman/NASA-GSFC

Hello:

I cloned and built using the README instructions (both permissive and non-permissive, and launched with / without sudo) and I get the OS_API_INIT error on startup.

I'm running the Ubuntu distro on Windows Subsystem for Linux. Surely that's the root cause. No urgent need to get it running, just wondered if this deployment is something on the roadmap for future support.

If more specific troubleshooting is desired, let me know how to gather the information and I'll get it for you.

Is your feature request related to a problem? Please describe.
From CCB discussions, should increment master revision on merges (except on *_version.h file)

Describe the solution you'd like
Automate via GitHub Actions, template started on branch in ci_lab that triggers

• still need to do update (via script, something like attached)
• still need to figure out how to commit (some key?)
• may need to be done remotely, triggered by GitHub and use a key to check back in

Describe alternatives you've considered
Update by hand (error prone)

Additional context
NA

Requester Info
Jacob Hageman - NASA/GSFC

It would be convenient to be able to run cppcheck in our checked out repo's without having to fish it out of the .travis.yml--what about moving it from .travis.yml to Makefile.sample and then having .travis.yml just call "make cppcheck"?

For that matter might be useful to add Make rules to "apt install" the required packages.

Requester Info
[email protected]

Currently apps define their perfid when using the performance logging framework, but there's no mechanism currently to ensure that the perfid is unique to that application and could result in confused perf logs.

One option would be to use the appid generated when the application is registered (but will need to be reported somehow so that a performance analysis tool can crosswalk from runtime-generated perfid's to the applications.)

A question related to the use of the time service provided by cfe.

I am trying to get time information using the API provided by cfe as follows:

CFE_TIME_SysTime_t time;
time = CFE_TIME_GetTime();

And I print it as follows:

char buffer[500] = {0};
CFE_TIME_Print(buffer,time);
OS_printf("%s\n",buffer);

But the printed year and time information seems to be incorrect. It indicates some value in 1980 as: 1980-012-14:03:20.00000. Also, when I launch cfe (core-cpu1), I see the following output which indicates the time starting in 2030 and then changing to some value in 1980.

2030-069-17:55:07.13648 SB internal message format: CCSDS Space Packet Protocol version 1
2030-069-17:55:07.13649 ES Startup: Calling CFE_TIME_EarlyInit
1980-012-14:03:20.00000 ES Startup: Calling CFE_TBL_EarlyInit
1980-012-14:03:20.00021 ES Startup: Calling CFE_FS_EarlyInit

Could someone please explain how I could obtain the correct current time information using the cFE APIs without having to resort to using functions in time.h?

Thanks!

Describe the bug
Likely related to travis-ci/travis-ci#6018 and similar reports the job log output gets truncated, often around the final documentation warning checks

To Reproduce
See build logs, for example https://travis-ci.com/github/skliper/cFS/jobs/328169033

Expected behavior
Full log should be shown to debug errors

Code snips
N/A

System observed on:
CI

Additional context
None

Reporter Info
Jacob Hageman - NASA/GSFC

I'm trying to get the syntax right for the validation command. I've been running gdb to look at the contents of the message. All I get is a cryptic invalid msg length error. With the following from the cFS-GroundSystem/Guid, instructions, I know I am not interpreting it right.

Originally posted by @JimKaidyNASA in nasa/ECI#42 (comment)

Is your feature request related to a problem? Please describe.
Update travis file for stricter cppcheck psp/fsw, osal/src/bsp, osal/src/os, fsw/cfe-core/src

Requester Info
Anh Van, NASA Goddard

Is your feature request related to a problem? Please describe.
All references in

Additional release notes for the cFS Framework are found in [release notes](https://github.com/nasa/cFE/tree/master/docs/cFE_release_notes.md).  See the [version description document](https://github.com/nasa/cFE/tree/master/docs/cFE_6_6_0_version_description.md) for the full version description document.  Test results can be found in [test results](https://github.com/nasa/cFE/tree/master/test-and-ground/test-review-packages/Results).  This is a point release from major development work currently being performed on an internal repository.

are broken.

Describe the solution you'd like
Fix links - relate to 6.7 release when available.

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC
Email from @dmccomas

This tool is specifically for the GSFC scheduler (a GSFC app), and is maintained by GSFC not the cFS framework community.

Currently copyright headers and the like are all over the map, this software would help automatically check that all of our copyright and license information is correct in every file in the cFS tree.

See: https://reuse.software/

Requester Info
[email protected]

I've tried running the cFE core-linux sample build in fresh VMs of CentOS 7, Ubuntu 16.04, and Ubuntu 18.04, and am getting the same error each time I try to run core-linux.bin:

CFE_PSP: Default Reset Type = PO
CFE_PSP: Default Reset SubType = 1
CFE_PSP: Default CPU ID = 1
CFE_PSP: Default Spacecraft ID = 66
CFE_PSP: Default CPU Name: CPU1
CFE_PSP: Starting the cFE with a POWER ON reset.
CFE_PSP: Clearing out CFE CDS Shared memory segment.
CFE_PSP: Clearing out CFE Reset Shared memory segment.
CFE_PSP: Clearing out CFE User Reserved Shared memory segment.
2029-107-16:47:31.25462 POWER ON RESET due to Power Cycle (Power Cycle).
2029-107-16:47:31.25465 ES Startup: CFE_ES_Main in EARLY_INIT state
CFE_PSP: CFE_PSP_AttachExceptions Called
2029-107-16:47:31.25466 ES Startup: CFE_ES_Main entering CORE_STARTUP state
2029-107-16:47:31.25467 ES Startup: Starting Object Creation calls.
2029-107-16:47:31.25467 ES Startup: Calling CFE_ES_CDSEarlyInit
2029-107-16:47:31.25470 ES Startup: Calling CFE_EVS_EarlyInit
2029-107-16:47:31.25474 Event Log cleared following power-on reset
2029-107-16:47:31.25474 ES Startup: Calling CFE_SB_EarlyInit
2029-107-16:47:31.25477 ES Startup: Calling CFE_TIME_EarlyInit
1980-012-14:03:20.00000 ES Startup: Calling CFE_TBL_EarlyInit
1980-012-14:03:20.00008 ES Startup: Calling CFE_FS_EarlyInit
1980-012-14:03:20.00016 ES Startup: OS_TaskCreate error creating core App: CFE_EVS: EC = 0xFFFFFFFF
CFE_PSP_Panic Called with error code = 0x00000006. Exiting.
The cFE could not start.

I get a few warnings when running make, but they don't seem to be a problem:

>>> [POST-BUILD] COPY BUILT FILES TO <CFS_PROM_APPS> <<<
 >> Create Directories <<
mkdir -p ./exe/cf
mkdir -p ./exe/cf/apps
mkdir -p ./exe/cf/log
mkdir -p ./exe/cf/upload
mkdir -p ./exe/cf/download
mkdir -p ./exe/ram

 >> Change Permissions <<
chmod 775 ./exe/*.bin
chmod 644 ./exe/*.so
chmod 644 ./exe/*.tbl
chmod: cannot access './exe/*.tbl': No such file or directory
../cfs.mak:232: recipe for target 'cfs_copy_installs' failed
make: [cfs_copy_installs] Error 1 (ignored)
chmod 644 ./exe/*.scr

 >> Copy Files <<
'./exe/core-linux.bin' -> './exe/cf/apps/core-linux.bin'
'./exe/ci_lab.so' -> './exe/cf/apps/ci_lab.so'
'./exe/sample_app.so' -> './exe/cf/apps/sample_app.so'
'./exe/sample_lib.so' -> './exe/cf/apps/sample_lib.so'
'./exe/sch_lab.so' -> './exe/cf/apps/sch_lab.so'
'./exe/to_lab.so' -> './exe/cf/apps/to_lab.so'
../cfs.mak:232: recipe for target 'cfs_copy_installs' failed
make: [cfs_copy_installs] Error 1 (ignored)

../cfs.mak:232: recipe for target 'cfs_copy_installs' failed
make: [cfs_copy_installs] Error 1 (ignored)
'./exe/cfe_es_startup.scr' -> './exe/cf/apps/cfe_es_startup.scr'

>>> DONE! <<<

There are no *.tbl files, which is causing the first couple warnings, and ./exe/cf/apps/cfe_es_startup.scr exists, so that seems to be fine as well.

I've tried this with the 6.5.0a release and building from master and see the same boot error.

Is your feature request related to a problem? Please describe.
github repositories are suggested to have a CONTRIBUTING.md document which describes best practices for developers wishing to contribute to the main release.

Describe the solution you'd like
Develop a CONTRIBUTING.md document with simple stuff like "follow the coding style guidelines", run unit tests prior to a pull request, etc.

Describe alternatives you've considered
Likely will need to incorporate or reference existing documentation. Could also use the wiki capabilities of dropbox.

Additional context
Add any other context about the feature request here.

Requester Info
Chris Knight, NASA Ames Research Center.

Is your feature request related to a problem? Please describe.
For noobs, it can be daunting to configure a cFS environment, or to find "that one parameter that changes the size of the pipe tables", for example.

Describe the solution you'd like
It would be nice to have a configuration ...generator...? that a user could use to quickly run through the configuration options (conditional code options, platform selection, sizing options) and generates the appropriate CMake files, .h files, startup scripts, etc.

Describe alternatives you've considered
menuconfig/kconfig (https://en.wikipedia.org/wiki/Menuconfig) is a popular option and provides a menu-based configuration system. Alternatively, a "wizard" style configuration (like Perl's Configure script) that steps through all of the configuration options, asking questions and providing default answers.

Whatever option is chosen, it should not replace the existing build process but should be a front-end to it, and provide human-readable/editable files as output that are equivalent to the current files.

Requester Info
[email protected]

Is your feature request related to a problem? Please describe.
Will need to update process when nasa/cFE#505 gets merged. This issue is to track getting the related cFS repo work done.

Describe the solution you'd like
Update based on new process

Describe alternatives you've considered
None.

Additional context
Also update #39

Requester Info
Jacob Hageman - NASA/GSFC

Describe the bug
sch_lab_app.c

int32 SCH_LAB_TblValidation(void *MySchTBL)
--
  | Parameter MySchTBL hides a global variable with the same name.
239 | {

To Reproduce
Steps to reproduce the behavior:

1. Build against lgtm

Reporter Info
Anh Van, NASA Goddard

Is your feature request related to a problem? Please describe.
Build config validation (from travis-CI) -
root: deprecated key sudo (The key sudo has no effect anymore.)
language: unexpected sequence, using the first value (c)
root: missing os, using the default linux
env: key matrix is an alias for jobs, using jobs

Describe the solution you'd like
See nasa/ci_lab@6cf5a57

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

Describe the bug
Command line arguments are not being parsed.

To Reproduce
Steps to reproduce the behavior:

1. Compile cFS
2. Run ./core-cpu1 --help

Expected behavior
Display help information

Code snips
The issue seems to be here. According to the man pages, getopts and getopt_long both require argc and argv passed on without modifications.

System observed on:

• Hardware: x86
• OS: Ubuntu LTS 18.04
• Versions:
  • cFE 6.7.17 (95f34d2),
  • OSAL 5.0.16 (c2bcebb),
  • PSP 1.4.11 (37ee8eb)

Reporter Info
NASA LARC

Is your feature request related to a problem? Please describe.
See #61
No current references to the generated documents

Describe the solution you'd like
Once the docs are deployed the first time (after push of #61 to master and CI completes) add references from at least README.md.

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

Is your feature request related to a problem? Please describe.
Process not documented

Describe the solution you'd like
Document process and reference.

• Issue requesting deprecation gets reviewed by CCB, accepted/assigned or rejected
  • evaluate requirements/documentation/operational impacts
• Pull request(s) wraps deprecated elements in *_OMIT_DEPRECATED ifndef and removes any internal dependencies
  • Default sample configuration does not remove this code
  • make OMIT_DEPRECATED=true prep will compile without it to check code for compliance
  • ideally any deprecated elements address dependency fix (use new element, no longer supported, etc)
  • elements can be deprecated in any build/release
  • CI tests with and without deprecated elements removed to ensure no internal dependencies
• Issue requesting removal of deprecated code
• Pull request removes deprecated elements
  • typically done end of cycle prior to a major release

Describe alternatives you've considered
Wing it.

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

Just upgrading some cFS mods we make in the lab with the software bus to this cFS build, but I've been running into some new pathing issues.

Notably, in case anyone else gets hung up on it, I have some CMake fail to finds:

ln 41 in global_function.cmake reads:

get_filename_component(MISSION_SOURCE_DIR "${CMAKE_SOURCE_DIR}/cFS/cFE" ABSOLUTE)

From this repo "psp" belongs to "cFS" but, this seems problematic in arch_build.cmake ln 26

include_directories(${MISSION_SOURCE_DIR}/psp/fsw/shared)

Also: "cFE" v "cfe" as the submodule in names sometimes gets in the way

After working with some of the pre-made utility apps provided by the CFE, I've noticed that at some point (relatively early) developers must abandon reuse in favor of clone/own which, in my opinion, is partly due to the CFS CMake build system not providing a clean method to push build configurations into the top level definitions folder.

An example of an app that could benefit from additional configuration would be the CI and TO lab apps. The current implementation of these apps use a hard coded port value for UDP communication with only a means to change the IP listened to via a command in TO Lab. My solution would most likely take the form of changing...

  #define cfgCI_PORT 1234

to...

  #ifndef cfgCI_PORT
    #define cfgCI_PORT 1234  // Default UDP port
  #endif

and having a config.cmake located within the missions definitions directory that contains the definition from a cmake instruction...

add_definitions(-DcfgCI_PORT=4321)

It would be nice for the CMake build system to provide the ability to have a companion configuration folder for each app in the definitions folder. This folder could contain headers and additional .cmake files used to specify certain details about the app being built.

It's currently possible to hijack the behavior of the targets.cmake file and add additional instructions like file(copy ...) to inject files into the app before it attempts to build but this would clobber the files currently present in the app directory.

Is your feature request related to a problem? Please describe.
Currently apps define their perfid when using the performance logging framework, but there's no mechanism currently to ensure that the perfid is unique to that application and could result in confused perf logs.

Describe the solution you'd like
One option would be to use the appid generated when the application is registered (but will need to be reported somehow so that a performance analysis tool can crosswalk from runtime-generated perfid's to the applications.)

Describe alternatives you've considered
Three alternatives: 1) a separate perfid registry/table in memory, 2) some sort of compile-time tool to generate ID's, 3) a textual identifier (that can be "namespaced".)

Additional context
Discussed at CCB 2019-09-04

Requester Info
Chris Knight, [email protected], NASA Ames Research Center

Describe the bug
unless I'm using git incorrectly, the submodule versions being pulled in don't match the commit histories in their respective github projects.

To Reproduce

1. clone cFS bundle and initialize the submodules
2. compare the submodule git logs from the specific github repos with the git logs in the submodule directories under the cFS bundle. I notice that the cFS bundle is not pulling in the latest commits from the submodules.

Expected behavior
submodule cfe "git log" commit history should match the github commit history in github/nasa/cFE, but it does not.

Code snips
N/A

System observed on:

• workstation
• OS: linux fedora 28
• Versions: latest github pull of cFS bundle

Additional context
the url config in the cFE submodule points to the correct github repo but its local commit history does not match what is shown on github

Reporter Info
RP - Astrobotic Tech

There are several places across various websites and documents that allude to the cFE API documentation, but I can't seem to find it anywhere. Does that actually exist? If so, could you point me to where that is? The application developer's guide is in the Git repository, but I'm specifically talking about the API documentation for cFE.

Is your feature request related to a problem? Please describe.
Send commands, receive telemetry section is out of date in README for python3

Describe the solution you'd like
Update instructions or link to submodule instructions?

Describe alternatives you've considered
N/A

Additional context
See also nasa/cFS-GroundSystem#50

Requester Info
Jacob Hageman - NASA/GSFC

Is your feature request related to a problem? Please describe.
Elements could be modified between original generation and use without easily being noticed. A holistic design approach to version control, reporting, integrity should be considered to support the various use cases.

Currently state:

1. Repo information (git describe in a subset of repos) is gathered during build and reported on execution for top branch, cFE and OSAL- need to expand this to include all the elements (apps, libs, psp, etc)
2. Build information is gathered during build and reported on execution - user name and date for last full build covering cFE (doesn't cover uploaded apps or elements built separately/after the original full build)
3. Version information updated by hand and reported at execution time for most of cFS - elf2cfetbl and tblCRCtool don't report version information, hasn't been consistently updated
4. Checksums are typically just calculated and reported at load/execution, doesn't cover libs, really should employ digital signatures that can be verified

Describe the solution you'd like
See above suggestions

Describe alternatives you've considered
None, but should discuss with security experts and come up with a complete, well vetted solution.

Additional context
Likely very beneficial to community requiring a more robust security approach

Requester Info
Jacob Hageman/NASA-GSFC

Is your feature request related to a problem? Please describe.
Current CI uses SIMULATION=native for all builds

Describe the solution you'd like
Add one non-simulation build, consider matrix model as used in osal

Describe alternatives you've considered
None

Additional context
nasa/cFE#629 - failure that wasn't caught

Requester Info
Jacob Hageman - NASA/GSFC