1. cFS User Community: Analysis and Recommendations

2. Contents About SKGS – why are we interested in cFS?
Our experience thus far
Description of survey results
Observations / Analysis of survey
Recommendations for the cFS community
9/17/2018

3. S&K Global Solutions (SKGS) & Why cFS?
SBA Certified Tribally-owned 8(a) Firm – Long relationship with NASA (support to JSC since 1997)
Incentivized to develop new businesses as a result of our Tribal ownership structure
Lots of exposure to cFS “from the outside” through our work at JSC (HDU; Morpheus; Lots of “buzz” within ER)
Clearly growing in popularity / usage; broad applicability
Brings a product line concept to embedded SW (true reuse)
Lots of potential as a commercial service line
Affiliation with S&K College (SKC)
Incentivized to partner with SKC and help develop new capabilities / highly relevant curriculum
Existing NASA relationships with visiting lecturers
Highly successful applied space flight program (BisonSat)
Tribal leadership made a strategic decision to develop technical competency and establish sponsored program specifically focused on cFS…..which brings us to this event!!
S&K Global Solutions, LLC
145 South Lake Crest, Suite 2
Polson, MT 59860
Phone:
FAX:
Point of Contact:
Mike Monahan
VP Business Development
Office:
Cell:
CAGE Code: 43CU2
DUNS:
Business Size: 8(a) - SDB
9/17/2018

4. Our experience as a “new user”
Constructing a Parts List: blind philosophers and the elephant
Partial app library / EDS / SIL / Hello World…….etc.
Governance challenges – re: OS Community
As an OS product – expectation user community will grow in size and diversity
Managing the core product line will become more critical
Funding constraints drive development priorities
Contrary to effective product line management
Not obvious that “program-centric” development produces the best SW
No clear “traditional” S&T funding streams….(SBIR/STTR or NSPIRES)
10 centers / 10 cFS’s
Created survey as a “first-step” to make sense of the data we were getting from discussions and research
Original intent was to develop an IDE….discovered it was a duplicative effort during this process
Bottom Line – hard to find a way to become a contributor to the cFS community due to disparate activity and thus hard to “develop” cFS as a technical competency…..
9/17/2018

5. Survey Description Done with Survey Monkey
Requested responses – cFS community, Johns Hopkins U/APL
41 development activities on survey
Respondents marked 1-5
1 – not helpful to support
5 – very helpful to support
28 respondents
Multiple analysis options tended to agree with one another
Look at central tendency for each question
Look at those with more “very helpful to support”
Look at those with “not helpful”
Compare weighted averages (we used this one)
9/17/2018

6. Survey – 28 Respondents
9/17/2018

7. Items with Weighted Av. Score Over 3
Items with Weighted Av. Score Over 3.5 (3 is mid-point: “Helpful to Support”)
Set up a standard cFS application development environment
Ensure that cFS development environment matches the actual deployment environment
Select parts of cFS for your project, finding the right files to download
Find relevant apps, PSP and OSAL libraries - e.g., apps store - one-stop shop for cFS core modules and flight-, hw- and OS-specific options
Configure an IDE (like Eclipse) with appropriate cFS modules, identifying changes for current application
cFS component configuration
Follow cFS application development standards
Conform to standards when identifying new commands and telemetry
Test
Unit Test
Integration Test
Test flight software integration
Simulate ground station controls and displays (commands and telemetry) for intermediate integration testing and debugging
Simulate H/W interactions for pre-H/W Integration testing
Document
9/17/2018

8. Survey Summary: Major cFS Development Pain Points
Setting up cFS development environment*
Commands and telemetry – conforming to standards
Testing – all levels*
Documenting
* received scores over 4.0
9/17/2018

9. Observations Each center of activity handles challenges on their own
Good: tailored to the needs of that organization
Bad: no one has much time to build tools
Bad: duplication of efforts
Bad: no coordination
Bad: a tool for one center will not fit other center practices
Bad: very little awareness of efforts at other centers
Observed with
Coordination of data and message definitions throughout development
Development of testing (unit, integration, simulation)
Getting started with cFE development
Testing is a major resource drain
Integration testing appears to have lots of potential for re-use
Re-use like cFE/cFS, for much the same reason - messages
9/17/2018

10. Recommendations
Embrace idea of Multiple cFS “Types” (e.g. - Human Rated / Non-Human Space Flight Rated / Hobbyist)
Preponderance of NASA use-cases are for non-human spaceflight, but the preponderance of funding is for development activity in support of Orion
Lander program at MSFC as an example
Multiple cFS types might allow for clean governance and help clarify center to center Area of Responsibility
Follow the Red Hat – Fedora model (stable core version for class A; optional “developmental” version for lower risk projects)
Focus some dedicated NASA resources on “core product line” maintenance and certification activity
Team would provide leadership for cFS tools / infrastructure (app library management)
Work toward establishment of a NASA standard/certification for space flight software developed in cFS
Create a cFS product line management funding stream that is separate from program-level funding
Embrace S&T activity that can support product line development (SBIR/STTR topics)
Near term – cFS community will benefit most drastically from improved testing capability
Data standardization is key to improved productivity / reusability
9/17/2018