1. V ERIFYING I MPLEMENTATION P ROTOTYPE Independent Test Capability Team - Bill Stanton - Jarrod Petersavage - Justin Morris - Steven Seeger - Mike Wise 1

2. VERIFYING IMPLEMENTATION 2 GOAL IVV 09-1: Verify System Behavior …Verify actual system behavior in the implemented system against expected (or designed) behavior… Engineering Services Initiative #10: Provide a capability to dynamically assess mission’s software against expected software behaviors. STEPS 1.Understand the Problem a. Vision b. Concept of Operations 2.Practical Example : Case Study a. Proof of Concept b. Role of the SRM c. Effort, Lessons Learned 3. Capture System Behaviors a. Models b. GUI Mockups c. Design Documentation 4.Acquire Supporting Tools and Develop Framework 5.Maintain Capability and Supports Applicable Projects

3. OBJECTIVES CASE STUDY APPROACH ROLE OF THE PBRA & SRM CASE STUDY RESULTS LESSONS LEARNED FUTURE WORK 3

4. CASE STUDY APPROACH Navigator Software on GPM Project 4

5. WHAT DID WE DO? Chose a Project  GPM Examined PBRA Results o GPM PBRA Profile: March 5, 2009 o GPM PBRA-Lite: May 28, 2009 Chose a small example  Navigator Software o Requirements: o Code is Available o Some Documentation Available o Supporting Tool(s) Available o Modeling Artifacts Available Successfully Run Code  Executed using EDGE IDE with SimTest Simulator o Develop and Execute Test Cases using Sequences from GPM SRM (Working) 5

6. R OLE OF THE PBRA AND SRM 6

7. GPM PBRA P ROFILE M ARCH 5, 2009, M ACAULAY, D UNKERLEY System Capabilities J1: Launch and Achieve Initial Orbit J2: Checkout Spacecraft J3: Fly in Required Orbits J4: Obtain Science Data J5: Maintain Health and Safety of Spacecraft J6: Process Science Data J7: Decommission Spacecraft J4 J1 J5 J6 J3 J7 J2 Impact 7 R OLE OF THE PBRA & SRM I DENTIFY T ARGET B EHAVIOR ( S )

8. “Maintain Health and Safety of Spacecraft Activity Diagram” 8 H H None H H H Maintain Propulsion System H

9. R OLE OF THE PBRA & SRM I DENTIFY T ARGET B EHAVIOR ( S ) 9 H H H H H M M M M L Maintain Propulsion System Activity Diagram Determine Position & Delta-V M

10. R OLE OF THE PBRA & SRM I DENTIFY T ARGET B EHAVIOR ( S ) Determine Position and Delta-V Behavior is implemented in the GPS Navigator The SC determines its position using GPS position information. 10

11. R ESULTS & L ESSONS L EARNED 11

12. C ASE S TUDY R ESULTS Identified a capability using PBRA & SRM to drive Verification Implementation Activities (Case Study) Executed Navigator Flight Software using a trial version of a COTS toolset in 2 months Duration includes obtaining all required tools and artifacts and configuring the environment Develop serial interface to provide conduit for testing Utilize Elaborated Sequence Diagrams (to be developed by SRMV PL) to drive test cases AccomplishmentsFuture Work 12

13. GPM Electrical Block Diagram 13

14. Navigator Software Simulation Navigator software runs on a FreeScale ColdFire 5307. On GPM, the Navigator is part of GN&C and connects to C&DH via RS-422. GPM has two Navigator units, but we only need to test one. Initial trial run used EDGE Development suite from Mentor Graphics. Compiled code as x86 without Nucleus OS code. Nucleus runtime provided by simtest. 14

15. Navigator Commands All Navigator commands and responses are transmitted over RS-422. ITC team determined that Navigator would be a good place to start because sending and receiving serial data is not difficult. Navigator commands over serial include read and write memory, patience, and ephemeris data. Easy proof of concept with simple write and read- back operation. Can expand simulation further with more complex commands. CCSDS message format. 15

16. Issues with Hardware Simulation Navigator has an RF board that receives GPS signals. Difficult to simulate. Developer uses complex hardware and software simulation solution. 16

17. Software Simulation End Goal Run binaries provided by vendors on an instruction set simulator. No need to compile Navigator software for x86. No chance of results varying by build process. More hardware interaction. Simulation Real hardware Headless operation with all simulations driven by test scripts. 17

18. L ESSONS L EARNED Working with Trial Versions of Tools often Proves Difficult Vendor Support 30-day to 60-day Trial Window Limited Tool Capabilities Importance of Communications between Product Lines Modeling Artifacts help drive Verification Implementation Activities Importance of SRMV and Verification Task Scheduling Initial setup time will vary depending on test environment and requirements Project Leads & Product Lines need to identify Verification Implementation targets early in lifecycle to allow time for tool acquisition, development time, and training Leveraging of Developer’s Capabilities may prove Beneficial  Parallel Activities 18

19. P ARALLEL A CTIVITIES O THER I TEMS BEING WORKED BY THE ITC T EAM N OT SCOPE OF PRESENTATION – I NFORMATION S HARING SoftSim All-digital system simulation with flight-like interfaces Juno and GRAIL missions VxWorks Utilized by almost all Science missions ITC is obtaining trial version, inquiring about licensing, and training License required to support SoftSim testing 19

20. A NY Q UESTIONS ? 20

21. B ACKUP S LIDES 21

22. P ROVIDES A DDITIONAL C APABILITY “S TATIC VERSUS D YNAMIC A NALYSIS ” Static AnalysisDynamic Analysis Finds weaknesses in exact location Allows quicker turnaround for fixes Finds errors earlier in lifecycle Automated Tools Relatively fast Can scan all of code Assess Mission Software against Expected Software Behaviors Finds run-time vulnerabilities Provide increased flexibility of what to look for Identifies vulnerabilities that may have been false negatives in static analyses Validation of Static Analysis Findings 22