verifying architectural design rules of a flight software product line
DESCRIPTION
TRANSCRIPT
CESE
1
Fraunhofer CESE:
Dharmalingam GanesanMikael LindvallChris Ackermann
Verifying Architectural Design RulesOf the Flight Software Product Line
NASA GSFC:
David McComasMaureen Bartholomew
CESE
What is the CFS?
• The Core Flight Software System (CFS) is a mission-independent, platform-independent, Flight Software (FSW) environment integrating a reusable core flight executive (cFE)
• The CFS is a product-line developed by the NASA Goddard Space Flight Center (GSFC)
2
CESE
Motivation for cFE/CFS
• Requirements– The Requirements for Command and Data Handling
(C&DH) Flight Software are very similar from Flight Project to Flight Project
– The Requirements for Guidance Navigation and Control (GNC) Flight Software are also be quite similar from Flight Project to Flight Project
• So, let’s not “re-invent the wheel” in each project– cFE responds to this by allowing FSW developers and
testers to concentrate on the uniqueness of a project
3
CESE cFE/CFS Heritage
IceSat GLAS (01/03)
XTE (launched 12/95) TRMM (launched
11/97)
MAP (launched 06/01)
SWAS
(launched 12/98)
WIRE
(launched 2/99)
SMEX-Lite
Triana
(waiting for launch)
TRACE
(launched 3/98)
SAMPEX
(launched 8/92)
Swift BAT
(12/04)
ST-5 (5/06)
Core FSW Executive
Future Spacecraft and Instruments
JWST ISIM (2011)
SDO (2007)
LRO (2009)
4
CESE
Business Goals and Arch. Principles
5
Reduce time to deployhigh-quality software
Reduce project schedule andcost uncertainty
Directly facilitate formalizedsoftware reuse
Enable collaboration acrossorganizations
Simplify sustaining engineeringand maintenance
Platform for advanced conceptsand prototyping
Common standards and toolsacross NASA
Layered architecture
Reusable core modules withstandard API’s
Plug and play modules
Standard Middleware/ Software bus
OS and Hardware Abstraction
Run-time module registrationand integration
Publish-and-subscribe style
The CFS Business Goals Supporting the Goals
CESE
Problem/Challenge• How do we make sure that the implementation
follows all documented architectural styles (e.g., Layers), patterns, interface usage rules, etc?
• Otherwise, architecture remains as a hypothesis• Technical goals can be compromised
– testability, buildability, (subtle) performance, run-time adaptability, evolvability, etc.,
• Also, business goals can be comprised because architecture is an important enabler
• cFE/CFS undergoes rigorous code review – are architecture rules already checked in review?
6
CESE
Specified Structure
7
…
CESE
Example cFE/CFS Context Diagram
Inter-task Message Router (SW Bus)
TranspondersCommands
Real-time Telemetry (UDP)
Comm Cards
File downlink (CFDP)
Summit Chip
MassStorageSystem
CFDP FileTransfer
FileManager
LocalStorage
DataStorage
EventServices
ExecutiveServices
TimeServices
1553 BusSupport
SoftwareBus
CommandIngest
Telemetry Output
TableServices
EDACMemory
ScrubberSelf Test
MemoryDwell
InstrumentManager
ChecksumMemoryManager
GN&CApplications
(4)
Mission Apps
cFE core App
CFS Applications
Stored Commanding
SoftwareScheduler
Health &Safety
Manager
House-keeping
LimitChecker
8
CESE
Approach for Verifying Rules
9
Mapping - sample
clonefinder grepifnamesRPASAVE
Bridge abstraction gap
CESE
Category of Derived (static) Rules• Dependency-restriction rules
– Fraunhofer SAVE , Relation Partition Algebra (RPA)
• Decomposition-restriction rules– RPA tool, grep
• Redundancy (clones) rules– Clone finder tool
• Conditional preprocessor usage rules– ifnames tool
Let us see sample results (details in the paper)
10
CESE
Why dependency-restriction rules?– a comment from cFE/CFS docs
• Developers are discouraged from using the OS_QueueCreate, OS_QueueGet and OS_QueuePut functions. These functions are a lower level duplication of the Software Bus Services pipes. Their usage limit the visibility into data messages being passed between Applications and they would also impose a requirement that two applications must reside on the same processor. 11
CESE
1212
Extracted Dependency from Code
This implemented view is consistent with the design guideline:
Cfe-app should use Cfe-core, but not vice-versa becauseCore should be independently testable/buildable without apps
App and Core are developedalmost by the same developers
CESE
1313
Extract Dependencies among Apps
No two applications are allowed to interact directly, and should instead use the software bus to communicateIt should be possible to start, stop, restart, and remove applications independently for improved fault tolerance.
Design Rule
CESE
OS Abstraction Layer (OSAL)• Real Time Operating System APIs
– Tasks, Queues, Semaphores, Interrupts, etc.,• File System APIs
– Abstracts the file systems that may be present on a system
– Simulate multiple embedded file systems on a desktop computer for testing
• Hardware APIs– Port and memory based I/O access in order to
provide a common way of accessing hardware resources 14
CESE
Why OSAL should be used? – comments from cFE/CFS docs
• The developer must make the effort to identify the proper methods through the cFE and OS API to satisfy their software requirements and not be tempted to take a “short-cut” and accomplish their goal with a direct hardware or operating system software interface.
• …attempting to write to EEPROM using the standard C function memcpy will fail. Using OS_MemCpy will succeed because the EEPROM will be configured for writing before the copy is performed.
15
CESE
OSAL By-Pass• The CFS guide states that all communications to the OS
and hardware should go through the OSAL for portability and testability reasons
• The analysis shows that there a few places where the OS is directly used (i.e., standard C functions)
CFE_ES_StartApplications call memsetCFE_FS_Decompress call memsetFS_gz_inflate_codes call memcpymain call printf
OS_Memset, OS_Memcpy, and OS_printfShould have been called 16
CESE
Common Look-and-Feel
• A common directory structure template has been defined– Where to place header files– Where to place configuration files– What data to make public (and private)
• Template for interaction with software bus and other core components
• Template for a module decomposition• Template for a task decomposition
17
CESE
Common Look-and-feel violations
18
QQ_AppMain
QQ_AppInit
QQ_AppPipe
QQ_VerifyCmdLen
QQ_HouseKeeping
…
LC_AppMain
LC_AppInit
LC_AppPipe
LC_VerifyCmdLen
LC_HouseKeeping
…
Limit Checker (LC)
QQ_AppMain
QQ_AppInit
QQ_AppPipe
QQ_VerifyCmdLen
QQ_HouseKeeping
…
QQ_AppMain
QQ_AppInit
QQ_AppPipe
QQ_VerifyCmdLen
QQ_HouseKeeping
…
LC_AppMain
LC_AppInit
LC_AppPipe
LC_VerifyCmdLen
LC_HouseKeeping
…
Limit Checker (LC)
LC_AppMain
LC_AppInit
LC_AppPipe
LC_VerifyCmdLen
LC_HouseKeeping
…
Limit Checker (LC)
If modules have different look-and-feelthey are difficult to inspect, test, understand.
Applications designed to interface with the cFE should follow standard templates.
In fact, found a subtle runtime error in a module that deviates from the QQ template. - Additional performance problems
CESE
Module Redundancy (Clone) Analysis
• The source code of the cFE/CFS is offered to some of its customers
• Presence of clones do not give good impression about the cFE/CFS design excellence
• Also, cloning is not a recommended way to implement product lines– Hard to evolve multiple cloned versions
19
CESE
Module Redundancy Analysis
• Clone finder tool detected a lot of “false” positives (mainly due to template code)
• However, there are some true clones within the OS abstraction layer (OSAL)
• There are no clones between Core and App layers (developed by the same team!)
20
Important tounderstand the contextbefore criticizing the team!
CESE
Conditional Preprocessor Analysis • Minimizing complexity is one of the
cFE/CFS design goals• Design decisions were made to use the
preprocessor to the “minimum”• 80% of files don’t have conditional
preprocessor statements!
21
Checks variation point lower and upper bounds
CESE
Variability Implementation Strategy• Missions can plug-in and plug-out
applications• Abstract APIs with alternative
implementations• OS and hardware variants are taken care
by the OSAL• Build scripts select and compile the
selected OS type implementation files• Header files with the same name is used
to manage certain variants 22
CESE
Conclusion and Outlook
23
• The cFE/CFS team performs rigorous design and code reviews thus not many issues remain!
• Nevertheless, some issues remain undetected
• Detected issues were added into the discrepancy list and were addressed
• Imagine the number of architectural violations in hardly reviewed systems!
CESE
Conclusion and Outlook• This analysis helped in establishing the
chain of relationships among business goals, architecture, and source code
• Important to verify whether the implementation is indeed consistent with the specified architecture– Tools help a lot in performing and repeating
• Otherwise, testability, buildability, performance, etc., can be compromised
• On-going work: run-time behavioral rules 24
