Contents

1. Introduction and Background

2. Getting to "Flight-ready" - our strategy <- New

3. Stepping Stones - our history of test platforms <- New

Introduction: Why are we testing?

Our CAN-Do! Widget is our means to attach payloads (Modules) to the IHU.  By building each payload (Module) with the attached CAN-Do! Widget providing the interface to the wiring harness of the spacecraft, the Module designer is assured a smooth integration with the spacecraft.

The module designer exercises the Module under test by creating a small CAN Bus cable to which is attached the Widget on the Module and a PC with either the Serial CAN232 Interface or the PCAN USB interface providing the means to attach the PC to the CAN Bus. We provide software (UHU and CDNC) which is installed on the PC (see center column at reference page) with which the designer can exercise all aspects of communication with the new Module through the Widget as if the IHU was talking to the Widget.  The CAN-Do! team wrote the software to utilize the precise messages over the CAN Bus which the IHU will use when communicating with Widgets on the spacecraft.

With the CAN-Do! team writing the AMSAT CAN communication specification, the Widget firmware, the UHU (and CDNC) software and lastly the IHU CAN communication elements we have assured that the CAN Bus communication is precisely controlled.  Essentially, we have implemented both ends of the CAN Bus communication and have tested each so that we are assured that it all works as intended.  Through this effort, independent of the Module designers, we ensure that the Module designers do not have to concern themselves with this part of the integration effort. We establish the expectation that if the new Module works with UHU (or CDNC), then it will work when the IHU is finally communicating with it.

So, in summary, why are we testing?  The CAN bus is the replacement for the I/O multiplexer found on earlier satellites. This is a mission critical system which must work as expected and must survive adverse effects.  It does allow for earlier integration-style testing as we've made communication with single modules the same as will occur when the IHU is running things.

In light of this criticality we take on multiple forms of verification. We are choosing to utilize both physical inspection/review and behavioral verification.

What is being reviewed? (physical)

•  Widget electronics implementation:
  •  See widget schematic at reference page on this website
  •  See electronics theory of operation in User Guide
•  Widget firmware implementation:
  •  Heavily commented source code (avail. from this site)
  •  User's Guide describing full operation (avail. from this site)
  •  Full line-by-line review of code (records kept)
    •  Findings reviewed and adjustments made to code and inline doc.
  •  Modeling of more complex behaviors (especially pipe-mode)
    •  Model reviewed and adjusted
    •  Findings applied back into code and inline documentation
    •  Implementation approaches altered where need identified
    •  Alternate implementation inspired by modeling effort was implemented which proved performance desirability of current implementation

What are we testing? (behavioral)

•  Widget electronics behaviors:
  •  Ability to withstand radiation
  •  Power consumed by the Widget
  •  The ability of the Widget to provide power to the attached Module
•  Widget firmware behaviors:
  •  Reaction to CAN Traffic
  •  Response CAN Traffic
  •  Communication with an attached Module:
    •  Mode-specific testing (Standard, Multiplex, and Byte-pipe)
  •  Ability to react to adverse conditions (Lockups, lost communication, etc.)
•  Traffic patterns on the CAN Bus:
  •  Making sure that our implementation of the Widget is generating the traffic that we expect to see on the CAN Bus
  •  Making sure that the traffic we are placing on the CAN Bus when communicating with a full complement of Widgets will work as we expect in terms of bus bandwidth utilization and in the face of error recovery
  •  Making sure that our CAN Bus still works in light of some of the failures that can occur
•  Traffic patterns on the proposed "Ring" CAN Bus topology:
  •  Identifying effects to normal traffic
  •  Determining which bus failure we can now survive