NASA Technical Reports Server (NTRS) 20170010200: A Generic Software Architecture For Prognostics A Generic Software Architecture for Prognostics

4.2 MB·English

by  NASA Technical Reports Server (NTRS)

A Generic Software Architecture for Prognostics
ChristopherTeubert1,MatthewJ.Daigle2,ShankarSankararaman3,KaiGoebel4,JasonWatkins5
1,2,4NASAAmesResearchCenter,CA,94035,USA
[email protected]
[email protected]
[email protected]
3SGT,Inc,NASAAmesResearchCenter,CA,94035,USA
[email protected]
5UniversityofCalifornia,Irvine,CA,92697,USA
[email protected]
ABSTRACT elsandalgorithms,aswellasthearchitectureandintegration
pieces.
Prognostics is a systems engineering discipline focused on
predictingend-of-lifeofcomponentsandsystems. Asarela- In fact, there are no known existing open software frame-
tivelynewandemergingtechnology,therearefewfieldedim- works for applying prognostics. That said, there are some
plementationsofprognostics,dueinparttopractitionersper- open prognostics tools, past prognostics research, and work
ceivingalargehurdleindevelopingthemodels, algorithms, in similar fields that form the foundational algorithms and
architecture, and integration pieces. As a result, no open toolsforsuchaframework. Oneexampleistheopen-source
softwareframeworksforapplyingprognosticscurrentlyexist. MATLAB Prognostics Model Library (Daigle, 2016b) and
ThispaperintroducestheGenericSoftwareArchitecturefor Prognostics Algorithm Library (Daigle, 2016a), which pro-
Prognostics(GSAP),anopen-source,cross-platform,object- vide some core model and algorithm implementations, but
orientedsoftwareframeworkandsupportlibraryforcreating no architecture or integration pieces. There are also some
prognosticsapplications. GSAPwasdesignedtomakeprog- general frameworks or operating systems that can be used
nosticsmoreaccessibleandenablefasteradoptionandimple- forsimilaroperations,suchasGeneralElectric’sPredixplat-
mentationbyindustry,byreducingtheeffortandinvestment form(GeneralElectric,2017),anindustrialInternet-of-things
requiredtodevelop,test,anddeployprognostics. Thispaper platform;theRobotOperatingSystem(ROS)(RobotOperat-
describestherequirements,design,andtestingofGSAP.Ad- ingSystem,2017),anopencollectionofsoftwareframeworks
ditionally,adetailedcasestudyinvolvingbatteryprognostics for robot software development; and NASA’s Core Flight
demonstratesitsuse. System(cFS)(NASA,2017),areusablesoftwareframework
forNASAflightprojectsandembeddedsoftwaresystems.
1. INTRODUCTION
This paper introduces the Generic Software Architecture
Prognostics is a systems engineering discipline focused on for Prognostics (GSAP), a general, object-oriented, cross-
predicting end-of-life (EOL) of components and systems. platform software framework and support library for prog-
EOLpredictionscanbeusedtoinformactionstomaintainthe nostics technologies. GSAP implements many of the func-
safety and efficiency of that system, either through mainte- tionsandalgorithmsusedinprognosticsaspartofaprognos-
nanceandrepairoronlinecontrolreconfiguration. Although tics support library. The GSAP framework implements and
a significant amount of research in prognostics technologies enforcestheprognosticprocess. Astandardinterfaceissup-
hasbeenperformedinrecentyears,therearefewfieldedim- pliedforintegratingnewmodelsandalgorithms,andforinte-
plementations of prognostics. This is due, in part, to practi- gratingthesystemintodatasources(sensors)andsinks(dis-
tionersperceivingalargehurdleindevelopingboththemod- plays, decision makers, etc.). Users are then able to create
their prognostic application by integrating their algorithms,
ChristopherTeubertetal.Thisisanopen-accessarticledistributedunderthe models,andinterfacestotheirsystemsintotheGSAPframe-
termsoftheCreativeCommonsAttribution3.0UnitedStatesLicense,which work,withpossibleintegrationonboardavehicleorremotely.
permitsunrestricteduse,distribution,andreproductioninanymedium,pro-
videdtheoriginalauthorandsourcearecredited.
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 1
INTERNATIONALJOURNALOFPROGNOSTICSANDHEALTHMANAGEMENT
This paper describes the design, testing, and use of GSAP. p(V ), where V = [v(k ), v(k + 1), ...,
ko,kh ko,kh o o
First, Section 2 provides a general description of the prog- v(k )].
h
nostics problem. Section 3 describes the current solutions
available for performing prognostics. Section 4 outlines the
Notethat,ingeneral,theseinputsaredependentonthetime
requirementsfortheGSAPsystem,andSection5outlinesthe
ofprediction,k .Further,p(.)denotestheprobabilitydensity
o
design chosen to meet these requirements. The testing, ver-
function,andtheseprobabailitydensityfunctionsneedtorep-
ification, and validation of GSAP is described in Section 6.
resenttheuncertaintyintheunderlyingquantities.TheGSAP
Section7describesacasestudywhereGSAPwasused. The
framework hence has systematic capabilities for uncertainty
finalsection,Section8summarizesthedesignandbenefitsof
representation,asdiscussedlaterinthispaper.
GSAPandprovidesasummaryoffuturework.
The prognostics problem, as solved by GSAP, is to predict
2. PROBLEMDESCRIPTION thefuturestatesofthesystemwithinatimeintervalandde-
terminetheoccurrenceofasetofevents:
Ingeneral,theproblemofprognosticsistopredictthefuture
evolutionofagivensystem,and,inparticular,topredictthe Problem 1. Given a time interval [ko,kh], an initial state
time of some (typically undesirable) event. In mathematical p(x(ko)), process noise p(Vko,kh), and future inputs
terms, we are interested in how the state of the system, x, p(Uko,kh), determinep(Xko,kh), andforeachevente ∈ E,
will evolve in time, whether some subset of the state space, computep(Oko,kh)andp(ke).
X, will be reached in some finite time, and, if so, when it
Here,k isthetimewheno (k)firstevaluatestotrue,i.e.,
willbeachieved(Goebeletal.,2017). Forexample,X may e e
representfailurestates,andtheearliesttimeatwhichafailure k (k)=min{k(cid:48) :k(cid:48) ≥kando (k)=true}. (3)
e e
stateisreachedistheEOL.Athresholdfunctiondefinesthe
boundarybetweenfailureandnonfailurestates.
Further, additional variables, z(k), that can be expressed as
In the general case, there are many different subsets of the functionsofthestatemayalsobepredicted:
statespaceofinterestrepresentingdifferentconditions,such
as failure/nonfailure, safe/unsafe, etc. For a state x ∈ Rnx, z(k)=g(x(k),u(k)), (4)
wedefineasetofeventsEthatapplytothestatespacewhere
whereg isanoutputfunction. Thus, p(Z )mayalsobe
foreache∈E wedefineathresholdfunction,T ,as ko,kh
e predicted. Notethatthepredictionsarealsoprobabilityden-
o (k)=T (k,x(k),u(k)), (1) sity functions (Sankararaman, 2015), and hence, the afore-
e e
mentioned uncertainty representation tools will also be im-
wherek ∈Nisthediscretetimevariable,u(k)∈Rnu isthe portant,fromthisperspective.
inputvector,ando (k) ∈ BisaBooleanvariableindicating
e
There are different methodologies to solve the Prediction
whethertheeventehasoccurredornot. Typically, o isde-
e
Problem (Problem 1), and GSAP does not enforce one over
finedonlyasafunctionofthestate,butingeneral,itmayalso
another. These are typically categorized into model-based,
betime-dependentandinput-dependent.
data-driven,andhybrid(combinedmodel-based/data-driven)
Forprediction,wewanttodeterminewhenthecurrentstateof approaches.
thesystemwillevolveintosomeotherstatewhereeoccurs.
Thestateevolvesaccordingtoastateequation: 2.1. Model-BasedPrognostics
x(k+1)=f(x(k),u(k),v(k)), (2) In the model-based prognostics paradigm, prognosis is per-
formed using a combination of a state estimation algorithm
where v(k) ∈ Rnv is the process noise vector, and f is the (often a Bayesian filter) and a prediction algorithm, both of
stateupdatefunction. which rely on a model of the monitored system (Orchard &
Vachtsevanos,2009;Daigle&Goebel,2013;Saha&Goebel,
The inputs to the prediction problem are the follow-
ing(Sankararaman,Daigle,&Goebel,2014):1 2009). Inthiscase,themodelmustincludethestateequation
(2),andanoutputequation:
1. atimehorizonofprediction,[k ,k ];
o h
y(k)=h(k,x(k),u(k),n(k)), (5)
2. theinitialstateprobabilitydistribution,p(x (k ));
o o
3. thefutureinputtrajectorydistribution,p(Uko,kh),where where y(k) ∈ Rny is the output vector, n(k) ∈ Rnn is the
U =[u(k ),u(k +1),...,u(k )];and measurementnoisevector,andhistheoutputequation.
ko,kh o o h
4. the future process noise trajectory distribution, The state estimation algorithm will estimate the state x(k)
based on the model and the measured outputs y(k). The
1Here, foravectora, wedenoteatrajectoryofthisvectoroverthetime
interval[k,k+1,...,kn]asAk,k+n. predictionalgorithmwillpredicttheevolutionofthestateto
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 2
INTERNATIONALJOURNALOFPROGNOSTICSANDHEALTHMANAGEMENT
computeitsfuturevalues,theoccurrenceofevents,andaddi- have formed the basis for the some of the models and algo-
tionalvariablesofinterest,z(k). rithms that were implemented in C++ for GSAP, along with
themodel-basedprognoser.
2.2. Data-DrivenPrognostics
In 2001, researchers at Boeing presented a high-level refer-
Inthedata-drivenprognosticsparadigm(Schwabacher,2005; ence architecture for intelligent vehicle health management
Schwabacher & Goebel, 2007), the mapping from u(k) and (IVHM) (Keller et al., 2001). This architecture included a
y(k) to k is learned offline, given historical data. The description of the required functions for IVHM in a layered
e
learnedmodelisthenusedonlinetocomputek givenmea- form. The authors recognized the importance of support or
e
suredsysteminputsandoutputs. logistics functions, such as those represented in the signal
processingandpresentationlayersoftheirarchitecture. This
2.3. HybridApproaches architecture is thorough but still only conceptual, stopping
shortofthedetailrequiredforimplementation.
Hybridapproachestoprognosticscombinemodel-basedand
data-driventechniques(Chen&Pecht,2012).Forexample,a
3.2. SoftwareFrameworks
particlefiltercouldbeusedtoestimatethesystemstate,and
thenk predictedusingalearnedneuralnetworkmodel. The Robot Operating System (ROS) is a set of open-source
e
librariesandtoolstobuildrobotapplications(RobotOperat-
3. SURVEYOFEXISTINGARCHITECTURES ingSystem,2017). Itincludesalgorithmscommontorobotic
applications,drivers,anddevelopmenttools. ROSusespack-
In this section, we describe existing prognostics software
ages, nodes, and services to provide functionality to robotic
andarchitectures(Section3.1),andsoftwareframeworksthat
systems. The ROS framework is completely open, allowing
sharesimilarcharacteristicstoGSAP(Section3.2).
userstocontributepackages,nodes,orservices. Thisissim-
ilartotheGSAPmodel,inwhichtheframeworkisdesigned
3.1. PrognosticsTools
tobeopensouserscanaddtechnologies.
Sinceprognosticsisarelativelyrecenttechnology, thereare
Core Flight Software (cFS) is an open-source platform and
no known existing open frameworks for applying prognos-
software framework for flight missions (NASA, 2017). It
tics. That said, there are some open prognostics tools, past
was originally designed by NASA for use with space mis-
prognostics research, and work in similar fields that is rele-
sionsbuthassincebeenadaptedforuseonaircraft. Itallows
vant. Theserelatedworksarehighlightedinthissection.
users to contribute components that integrate into cFS using
Inlate2016,thePrognosticsModelLibrary(Daigle,2016b) a standard interface. Common tools for flight missions are
andPrognosticsAlgorithmLibrary(Daigle,2016a)werere- implemented and incorporated into the software, and there
leased as open-source software. The Prognostics Model Li- have been some efforts to extend cFS for specific applica-
brary is a MATLAB-based modeling framework, with a par- tions. OnesuchexampleistheAutonomyOperatingSystem
ticularfocusondefiningandbuildingmodelsofengineering (AOS), a NASA effort to extend cFS to support autonomy
systems for prognostics. It includes a library of prognostics aircraftoperations.
models for select components developed within this frame-
Predixisageneralclosed-sourceIndustrialInternetofThings
work,whichisamenableforusewithinprognosticsapplica-
(IIoT)platformdevelopedbyGeneralElectric(GE)(General
tions for these components in relevant systems. The Prog-
Electric, 2017). It provides data management and data sci-
nosticsAlgorithmLibraryisaMATLAB-basedsuiteofalgo-
ence tools to industry and includes a marketplace of con-
rithms commonly used within the model-based prognostics
tributed applications that provide additional capabilities. It
paradigm. As such, it includes algorithms for state estima-
ismodularandhasastandardinterfacefordeveloperstoadd
tion and prediction, including uncertainty propagation. The
technologies.
algorithms rely on component models developed within the
PrognosticsModelLibraryasinputsandperformestimation ROS, cFS, and Predix are each platform to support a wide
andpredictionfunctions. Thelibraryallowstherapiddevel- number of capabilities in their target environment. GSAP is
opmentofprognosticssolutionsforgivenmodelsofcompo- a platform that instead supports a particular capability, i.e.,
nentsandsystems. Further,sincethemodelsandalgorithms prognostics,inawidevarietyoftargetenvironments. Bytar-
areimplementedasobjects,itfacilitatescomparativestudies geting a very specific application, GSAP can provide many
andevaluationsofvariousalgorithmstoselectthebestalgo- advancedfeaturesforprognostics. Further, GSAP,likeeach
rithmfortheapplicationathand.Theselibrariesbothsupport oftheseplatforms,ismodularandsupportsthedevelopment
the design, creation, and testing of prognostics algorithms of new tools or modules. A GSAP application could poten-
and models, however, they do not address the problems of tially integrate as an application into any of these platforms
prognosticsystemdesign, architecture, andinterfaces. They byadoptingthenecessaryinterfaces.
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 3
INTERNATIONALJOURNALOFPROGNOSTICSANDHEALTHMANAGEMENT
4. REQUIREMENTS Performance Cost Schedule
The development of requirements for prognostics systems
continues to be an important and popular topic of re- 4: Implement
1: Error Handling Common Elements
search(Goebeletal.,2017;Saxenaetal.,2010,2012;Leao, 2: Uncertainty 5: Common Interface
Yoneyama, Rocha, & Fitzgibbon, 2008; Usynin, Hines, & Representa7on 6: Flexible to Support
3: Parallelize Different Schemas
Urmanov, 2007). Defining clear and complete requirements
7: Minimize Effort to
for prognostics applications is important. All top-level re- Extend
quirements for a system can be thought as deriving from
performance, cost, or schedule goal (Saxena et al., 2012;
SAEAerospace,2017).
Figure1. GoalsandTop-LevelRequirementCorrelation
Similarly, for GSAP, the purpose is to provide a tool to be
usedinprognosticsapplications,improvingtheperformance,
cost, andscheduleofthoseapplications. Inthiscontext, the
goalsofGSAPare:
Goal 1. Improve the performance of prognostics applica-
tions.
Goal2. Reducethecostofcreatingprognosticsapplications.
Goal3. Improvethescheduleforcreatingprognosticsappli-
cations.
Figure2. UsingGSAP
ThesegoalstranslateintoGSAP’stop-levelrequirements. A
listofthetop-levelrequirementtopicsisincludedbelow. The Extendable to support new prognostics targets, types of
flowdownfromgoalscanbefoundinFig.1. prognosis,andintegrationintonewsystems.
Scalable tosupportlargeapplicationswheremanysystems
ErrorHandling Providebasicerrorhandlingandreporting arebeingmonitoredinparallel.
forimprovedprogramresilienceanddebugging
SeeAppendixBforcompleteGSAPrequirements.
UncertaintyRepresentation Provide a manner of repre-
sentinguncertainty
5. DESIGN
Parallelize Parallelizeoperationswheneverpossibleforin-
creasedperformanceandreduceddependenciesbetween This section describes the overall design of GSAP. At the
theperformanceofseparateprogramelements. highest level, GSAP consists of two parts: The Prognostics
Framework and the Prognostics Support Library. These are
ImplementCommonElements Implement the common
compiled with any user layer contributions to build a prog-
algorithmsandfunctionsofprognosticsapplications
nosticsapplication,asshowninFigure2.
CommonInterface Provide a common interface for inte-
In the remainder of the section, we describe the design in
gratingnewtechnology
detail. Section 5.1 describes the design patterns utilized in
FlexiblitytoSupportDifferentSchemas Support differ- GSAP. Section 5.2 and 5.3 describe the prognostics frame-
entformsandmethodsofperformingprognostics workandsupportlibrary,respectively. Section5.4describes
MinimizeEfforttoExtend Reduce the effort required to the user layer. The ModelBasedPrognoser is described in
extendGSAPwithnewprognosticstechnologies Section5.5.
Alistofnon-functionalrequirementtopicscanbefoundbe- 5.1. DesignPatterns
low:
GSAPleveragesmanywell-establisheddesignpatterns. Un-
derstanding these patterns is essential for understanding the
Compliance with NASA and industry standards and prac- designofGSAP.Thissectionprovidesabriefdescriptionof
tices (National Aeronautics and Space Administration, someofthedesignpatternsfoundinGSAP.
2017,2014;CMMIProductTeam,2010).
Documentation in an accurate, and efficient manner to 5.1.1. Singleton
supporteaseofuse.
Singletonsareclassesofwhichonlyasingleinstanceexists,
Open-Source GSAPtoprovidethegreatestimpact. whichissharedbyallprogramelementsthatneedtousethe
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 4
INTERNATIONALJOURNALOFPROGNOSTICSANDHEALTHMANAGEMENT
class. GSAPusessingletonsinsituationswhereastaticclass
Started
might be appropriate, but there is significant code that can Start Stop
be shared between classes, making inheritance useful. By
creating a singleton, we achieve the benefits of shared code Enabled
Stop
viainheritancewhileallowingallelementsusingtheclassto
Pause
Resume/Start
sharestatebyusingasingleinstance.
Stop
Examples of singleton classes in GSAP include the various
Paused
Factoryclasses,theThreadSafeLog,andtheCommManager
class. SingletonsinGSAPinheritfromthesingletonabstract
Figure3. GSAPPrognoserControlStates
baseclass(ABC).
5.1.2. Facade
A facade class simplifies access to a larger body of code.
GSAP uses a facade to wrap the complexities of cross-
platform networking code into the TCPSocket and UDP- work.Assuch,factoriesareusedtoinstantiatealargenumber
Socket classes. These classes expose all of the network oftheframeworkandsupportlibraryclasses.
communicationfunctionalitythatGSAPrequiresinasimple
cross-platform class for each protocol where the users need 5.2. PrognosticsFramework
onlyconcernthemselveswiththeSendandReceivemeth-
The framework contains the core functionality for running
odsofthesocketclasses.
GSAP,includingthelogictoinitiateandrunprognostics.The
primary class is the ProgManager. Initialization and control
5.1.3. AbstractBaseClass
of GSAP applications is achieved through this class, as de-
Although not strictly a design pattern, abstract base classes scribed in Section 5.4.2. The ProgManager reads the main
(ABCs)areadesignstrategyusedextensivelybyGSAP.Ab- configurationfile,startstheCommManagerclass,andcreates
stract base classes define an interface and shared core func- theprognosers,eachonadedicatedthread.TheProgManager
tionality of an object while leaving the concrete implemen- also handles the receipt of control commands, such as start,
tationofthefunctionalityrepresentedbytheABCtobeim- stop,pause,andresume. Figure3showsthedifferentopera-
plementedinvirtualmethodsoverriddenininheritingclasses. tionalstatesofaGSAPapplication.Prognosticstepsareonly
This concept is used in conjunction with the factory pattern executedwhentheapplicationisintheStartedstate.
described in Section 5.1.4. Factories need only be aware of
On creation, the CommManager initializes the communi-
theABC;itdoesnotneedtoknowanythingaboutimplement-
cators specified in the main configuration file, configured
ingclasses.
according to their particular configuration file (see Sec-
ThereareseveralABCsinGSAP.TheseclassesincludeCom- tion 5.4.1). It then handles the following: 1) update and re-
monCommunicator, CommonPrognoser, Model, Observer, ceipt of sensor data by the communicators, 2) requests for
and Predictor. This is the main mechanism by which a user sensordatabytheprognosers,3)updateofprognosticsresults
can extend GSAP Each of these classes defines an interface by the prognosers, and 4) requests of prognostics results by
that users can implement their inheriting classes to extend thecommunicators. Uponreceiptofthestopcommandfrom
GSAPwithcustomtechnologies. theProgManager,theCommManagerwillstopandcleanup
allthecommunicators.
5.1.4. Factory
Perhapsmostimportantly,theframeworkincludesallthein-
Factoryclassesprovideamethodforinstantiatingobjectsin- terfacesforeachofthemodulesintheuserlayer.Thesecome
directly. GSAP uses factories extensively for classes in the intheformofAbstractBaseClasses(ABC),asdescribedin
frameworkwhicharelikelytobeimplementedinpracticeby Section 5.1.3. Each ABC defines the interface with which
theenduserextendinganabstractbaseclassprovidedbythe the higher-level framework communicates with the concrete
frameworkorsupportlibrary. Byallowingtheendusertoex- inheriting classes. For example, a concrete prognoser could
tendabaseclassandthenregistertheextendedclasswiththe becreatedtoinheritfromitsABC,CommonPrognoser. The
factory, the framework can use user-supplied classes speci- concreteprognoserwouldthenberequiredtoimplementthe
fiedinconfigurationfileswithoutbeingdirectlyawareoftheir virtual methods defined in the ABC. They would also have
concreteexistence. the option to implement the optional virtual methods which
would provide additional advanced features. Implemented
AlargepartoftheflexibilityofGSAPisderivedfromtheex-
optionalmethodsoverridetheimplementationpresentinthe
tensiverun-timeconfigurationoptionsprovidedbytheframe-
ABC.
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 5
INTERNATIONALJOURNALOFPROGNOSTICSANDHEALTHMANAGEMENT
ing prognostic history files, saved in the path identified as
CommonPrognoser
+results: ProgData histPath in the Prognoser Configuration File. Each specific
+comm component has a history file, identified by the component’s
+step()
unique id (the id field in the Prognoser Configuration File).
+checkInputValidity()
+bool isEnoughData() Thestateissavedtothisfileperiodicallywhiletheprognoser
+checkResultValidity()
ConcretePrognoser isrunningandonterminationofGSAP.Iftheuserwouldlike
to reset the history file, the resetHist flag can be used. This
is done if maintenance or a change of configuration has oc-
Figure4. PrognoserDesign
curred,causingtheconfigurationfiletonolongeraccurately
Table1. CommonPrognoserConfigurationParameters reflectthestateofthesystem.
Thestepfunctioniscalledonceeverytimestep. Insidethe
Key Description
stepfunction,theprognosorcanaccesssensordata,perform
type The type of prognoser (ex: model- calculations, and populate a ProgData (see Section 5.2.2)
BasedPrognoser) structurewiththeresults. Foranexampleofanemptyprog-
name The name of the component being noser, with explanations of each member function, see Sec-
prognosed(ex: battery1) tionA.1.
id A unique identifier for the piece of The optional functions checkInputValidity and
hardwarebeingprognosed(ex: Serial
checkResultValidity are called once a timestep.
Number)
Thesefunctionscanbefilledwithbasicsanitychecks,tosee
histPath(Optional) Apathforthehistoryfiles
if the input or results make sense. The most basic form of
inTags(Optional) A list of tags expected from commu- these is a check to make sure that the sensor values fall in a
nicators certain range. These checks can spot sensor problems that
resetHist(Optional) Aflagtoresettherecordedhistoryfor mightleadtoanincorrectprognosis. Iftheyarenotincluded
the component. Will archive the cur- withtheprognoser,nocheckwillbedone.
renthistoryfileandstartanewone
ThealsooptionalisEnoughDatafunctionisusedtodeter-
mine if there is enough new, valid data for prognosis. This
5.2.1. Prognosers functionreturnsabool. Iffalseisreturned, prognosticswill
notberunthattimestep.
This is the core of the GSAP system. Inside the prognosers
is the core logic for performing prognostics. A new prog- GSAP is currently distributedwith oneprognoser, theMod-
noseriscreatedtosupportanewmethodforperformingprog- elBasedPrognoser. This prognoser defines the model-based
nostics. Manyprognosticssystemsfollowastandardmodel- prognosticsparadigm. Usingthisprognoserrequiresusersto
basedstructure. Thosesystemsdonotrequirethecreationof supply a model of the system. The exact workings of this
a new prognoser, only the creation of a new model that will prognoseraredefinedinSection5.5.
beusedbytheModelBasedPrognoser.
5.2.2. PrognosticDataStructure(ProgData)
All prognosers must inherit from the base Common-
Prognoser class (see Figure 4). Prognosers must have ThePrognosticsDataStructure,ProgData,isaclassforstor-
a constructor and a step function, but they can option- ingandaccessingtheresultsofprognosticsinastandardway.
ally also implement the other virtual member functions Each prognoser has a ProgData structure, which it fills with
checkInputValidity(), isEnoughData(), and the results. Communicators can then access the progData
checkResultValidity(). In the constructor, the structures for publishing results. The structure of ProgData
prognoser is configured from a map of the configuration canbeseeninFigure5.
parameters from that prognoser’s configuration file. This
At the highest level, each prognoser has a prognoser name,
configurationmapisreceivedasaconstructorargument.
componentname,anduniqueidentifier. Theprognosername
Each prognoser has a configuration file, which defines the is the type of prognoser used, while the component name is
configuration of that prognoser. Individual prognosers can a name for the particular component targeted. The unique
have custom configuration parameters, which are docu- identifier is an identification string or number unique to that
mented with the prognoser. A list of the configuration pa- physical component (e.g. serial number). The unique iden-
rameterscommontoallprognoserscanbeseeninTable1. tifier should change if the component is replaced. For ex-
ample, if a battery is being prognosed it might have the
When the prognoser is started, it is initialized with the last
prognosername“Battery”,thecomponentname“Batt5”(re-
state for that component (with the same id), if prognostics
ferring to the specific battery location), and a unique id
has been run before on that component. This is done us-
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 6
INTERNATIONALJOURNALOFPROGNOSTICSANDHEALTHMANAGEMENT
Table2. PrognosticEvents
ProgData
+internals
Field Description
+ProgData(prognoserName, componentName, uniqueID)
timeOfEvent The time the event will occur with un-
certainty(UDatatype).
+sysTrajectories +events
eventProb Thescalarprobabilityofeventoccuring
ProgEvent
withinthepredictionhorizon.
DataPoint
+timeOfEvent
+eventProb probMatrix The probability that the event will oc-
+probMatrix cur at each time stamp. A one degree
+occurrenceMatrix vector where probMatrix[x] is the
probability that the event will occur at
time[x].
Figure5. PrognosticDataStructure
occurrenceMatrix A 2-dimensional matrix storing if an
eventhasoccuredforeachsample. Isa
time x unweighted samples matrix, so
“1394snvsdoe2” for that specific battery. These values can that occurrenceMatrix[0][7]
besetintheconstructororusingtheset*()methods(e.g. represents if the event has occured for
sample7attime0.
setPrognoserName()).
TheProgDatastructurecontainsastructureofsystemtrajec-
tories. Thesecorrespondtothepredictedoutputsz(k)andits CommonCommunicator
corresponding trajectory Zko,kh. These system trajectories ++pDoaltl(a)Store read()
aretypicallyusedtostoreinformationaboutsystemvariables
+write(AllData)
that measure the degradation or fault severity. Common ex- +setRead()
amplesoftheseareStateofHealth(SOH)orStateofCharge ConcreteCommunicator
(SOC)forbatteries. Potentially,thesecouldalsoincludeop-
eratingefficiencyoranyotherderivedquantitythatrepresents
Figure6. CommunicatorDesign
performance. Systemtrajectoriesareaccessedbyname,e.g.,
pData.systemTrajectory["SOH"]. Thevalueofthe
systemtrajectoryisstoredwithuncertaintyasaUDataobject networkmessagingsystem(e.g.,SCADA,CAN).Thesesys-
(seeSection5.3.1). tems can receive data which will be used by prognosers or
communicatetheresultswithoperators.
TheProgDatastructurealsocontainsastructureofprognos-
tic events that can occur, i.e., E as defined in Section 2. AllcommunicatorsmustinheritfromthebaseCommonCom-
Each prognostics event has a name (e.g. EOL) and time municatorclass(SeeFigure6). Communicatorsmusthavea
unit (e.g. cycles). Events are accessed by name, for exam- constructor, a poll, a read, and a write function. In the con-
ple pData.events["EOL"]. The information for each structor, the communicator is configured from a map of the
eventislistedinTable2. Eacheventmustpopulatethetime- configurationparametersfromthatcommunicator’configura-
OfEventfield.Theotherfieldsareoptional,eachfieldprovid- tionfile. Thisconfigurationmapisreceivedasaconstructor
ingadditionalinformationabouteventprobabilitywithuncer- argument.
tainty. Forexample,theeventoccurrencetrajectoriesO
ko,kh Thepoll()functioniscalledperiodicallytocheckifthere
(seeSection2).
is more data to read. If there is data to read, the commu-
Theinternalsfieldisusedtostoreanyinformationinternalto nicator will call the setRead() function to indicate that,
the prognoser that is not to be published. Everything in the and the read function will be called. In the read() func-
internalsfieldisstillsavedtothehistoryfileforreinitializa- tionthecommunicatorwillfillaDataStorestructurewith
tion. Users have an option to save internal parameters that any received data. The DataStore structure will then be
arenotimportantforreinitializationasmembervariables,but returned. The write() function is used to communicate
notethatthesewillnotbesavedbetweenruns. prognosticresultstodatasinks. Foranexampleofanempty
communicator, with explanations of each member function,
5.2.3. Communicators seeSectionA.2.
Communicators are used to communicate data with the out- Each communicator has a configuration file, which defines
side world. These function as interfaces with various data the configuration of that communicator. Individual commu-
sourcesandsinks. Someexamplescouldbeaplaybackagent nicatorscanhavecustomconfigurationparameters,whichare
thatreadsfromafile,aGUIfordisplayingprognosticresults, documentedwiththecommunicators.Onlyoneconfiguration
an automated report generator, or a client that connects to a parameteriscommontoallcommunicators,thetype. Like
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 7
INTERNATIONALJOURNALOFPROGNOSTICSANDHEALTHMANAGEMENT
forprognosers,thisisusedtospecifythespecificcommuni- Table3. GeneralSupportClasses
catortobecreated(e.g. type:playback).
GSAP is currently distributed with three simple communi- Function Description
cators: Playback, Recorder, and Random. These are basic Logger Asingletonloggerwithmultiplemessagever-
functions that are often performed in many prognostics ap- bositylevelsdesignedforamulti-threadeden-
vironment. Loggingmessagesissimilartouse
plications. Additionally, many tools such as cross-platform
ofprintf
TCP/UDP socket classes, which aid in the development of
other common communicators, are supplied in the Prognos- Configuration A map data structure for loading, accessing,
Map andparsingconfigurationfromakey:value1,...
tics Support Library. The included communicators are de-
stylefile
scribedbelow.
TCP Socket Aclassforconnecting,sending,andreceiving
&Server TCPstreamdataoveranetwork
Playback This communicator is used to read sensor data
fromadelimitedfile. Thefilemustincludeaheaderrow UDPSocket Aclassforconnecting,sending,andreceiving
withthenamesofeachvalue. UDPdatagramdataoveranetwork
Recorder Thiscommunicatorisusedtorecordsensordata Singleton Asuperclassforsingletonclasses.Enforcesthe
interfaceforthesingletondesignpattern
and prognostics results to a delimited file. The file in-
cludesaheaderrowwiththenamesofeachvalue. Factory A superclass for factory classes. Enforces the
factorydesignpatternforcreatingnewobjects
Random Thiscommunicatorisusedfortesting. Itsetsthe
value of every sensor to a random number in a range UData Uncertain Data Structure Classes - Classes
usedforstoring,distributing,andmanipulation
specifiedintheconfigurationfile.
datawithuncertainty
5.3. PrognosticsSupportLibrary Thread A superclass for classes with a dedicated
thread. Enforces finite state machine status’s
The support library is a collection of tools to support prog- andstandardcontrolinterface
nosers, communicators, and the framework. Each of these
Statistical Asetofstatisticaltools
classes provides functionality to GSAP that can be used as Tools
part of a GSAP application, or externally with other prog-
Matrix Aclassforstorage andmanipulationofanar-
nosticsproducts. Theseclassesareallthoroughlytestedand
bitrary2-DMxNmatrixofdoubles
designedtobelight,cross-platform,andeasytouse.Thesup-
Exceptions CustomexceptionsforGSAPapplications
portclassesincludedandadescriptionoftheirusearegiven
inTable3. Benchmark AprognoserforbenchmarkingGSAPapplica-
tions
5.3.1. UncertaintyRepresentation
The GSAP support library includes tools for the represen-
3. u[MEAN] = 10;
tation of variable uncertainty, through the “UData” class. 4. u[SD] = 0.5;
A single random variable can be expressed using either a 5. printf("u(%f,%f) was last updated %f\n",
parametric distribution type or a non-parametric distribution u[MEAN], u[SD], u.updated());
type. To describe a parametric distribution, it is necessary
to know the distribution type (Gaussian, log-normal, etc.) In this example, a parametric UData object of uncertainty
andthedistributionparameters(forexample,meanandstan- type mean with standard deviation. On line 2 the distribu-
dard deviation in the case of a Gaussian distribution). A tion type is set to gaussian. The mean is set to 10 and the
non-parametric distribution can be expressed regarding un- standarddeviationissetto0.5(lines3-4). Thevalueofuand
weighted(i.e.,equally-weighted)samples,weightedsamples, thetimeitwaslastupdatedaresetonline5.
percentiles and percentile values. A vector of random vari-
Belowisanexampleusinganon-parametrictype:
ables can be statistically dependent and follow varied distri-
butiontypes;presently,thegenericarchitecturesupportsonly 1. u.uncertainty(SAMPLES);
2. u.npoints(100);
theinclusionofavectorofrandomvariableswheneachvari-
3. u.set(sampleVec);
able is individually Gaussian, in which case, the statistical 4. u[22] = 3;
dependence can be completely expressed using the covari- 5. for (auto & sample : u) {
ance/correlationmatrix. 6. // Some action
7. }
Belowisanexampleusingaparametrictype:
On line 1 and 2, the uncertainty type is set to samples (un-
1. UData u(MEANSD);
2. u.dist(GAUSSIAN); weighted) with a size of 100 samples. The samples are set
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 8
INTERNATIONALJOURNALOFPROGNOSTICSANDHEALTHMANAGEMENT
Table4. TopLevelConfigurationParameters
Key Description
Prognosers Alistoftheprognoserconfigu-
Main Config File rationfilestouse. Aprognoser
will be made for each configu-
rationfileinthelist
Communicators Alistofthecommunicatorcon-
figuration files to use. A com-
municator will be made for
Prognoser Config File Communicator Config File
eachconfigurationfileinthelist
commmanger.step size Waittimebetweeniterationsof
Figure7. ConfigurationFileHeirarchy
(Optional) the commmanager in millisec-
onds
tothecontentsofavector, andthe22ndsampleisoverwrit-
Anexampletop-levelconfigurationparametercanbeseenbe-
ten with the value 3. In lines 5-7 the samples are iterated
low:
through. Line6canbereplacedwithanyactionactingonthe
singlesample. # Example Configuration File
Prognosers:Batt1.cfg,Batt2.cfg,Motor1.cfg
Communicators:Recorder.cfg, Playback.cfg
5.3.2. AlgorithmandModelLibraries
histPath:../test/validation/hist
commmanger.step_size:1000
The Prognostics Support Library also includes a selection
of common algorithms used with Prognostics, including ob-
Configuration for prognosers and communicators are de-
servers,predictors,andsystemmodels.Thesealgorithmsand
scribedinSections5.2.1and5.2.3,respectively.
modelsaredescribedinSection5.5.
5.4.2. PrognosticsApplicationDriver
5.4. UserLayer
ThePrognosticManagermustbecreatedandcalledbysome
Theuserlayerconsistsofthevariablesections,or”hotspots”
higherlevelapplication. Thisistheonlycustomcodestrictly
of GSAP (Srinivasan, 1999). Users create new modules in
required to build a custom application if the user is using
thislayertoconfigureGSAPtotheirspecificapplication.
the provided prognosers and communicators. In this docu-
UsersmusthaveaPrognosticsApplicationDriver(PAD)(see ment,thisisreferredtoasthePrognosticsApplicationDriver
Section5.4.2),tostartGSAPandconfigureit. Userscanalso (PAD).TheprimaryroleofthePADistocreateandstartthe
configuretheirprognosticsapplicationthroughthecreationof Prognostics Manager, which will initiate prognostics. To do
customprognosersandcommunicators,describedinthefol- thisrequiresthefollowingtwolines:
lowingsections. Theprognosersandcommunicatorsusethe
ProgManager PM = ProgManager(ConfigFile);
facadedesignpattern,supplyingaparentclasswithaprede-
PM.run();
finedinterface. Userscreateclasses,whichderivefromthese
parentclassesandimplementtherequiredfunctions.
HerethefirstlinecreatestheProgManagerandconfiguresit
tousetheconfigurationfilespecified(here,shownasastring
5.4.1. Configuring
variableConfigFile). Thesecondlinestartstheprognos-
GSAPusesatwo-layerhierarchicalstructureofconfiguration ticmanager.
filestoconfigureallthecomponentstoaspecificapplication,
Optionally, users can include their components to extend
asseeninFigure7. Theseconfigurationfilesincludealistof
GSAPcapabilities. ThesecomeintheformofcustomCom-
key:valuepairs. Commentscanbeincludedbystartingaline
municators,Prognosers,Models,Observers,orPredictors,as
witha’#’character.
described in the following sections. When custom compo-
Thetop-levelconfigurationfilecontainsalltheparametersfor nents are used, it must be registered with its respective fac-
configuring the ProgManager. The most important of these tory. Anexampleforacustomprognoserisincludedbelow.
parameters is the identification of the configuration files for In this case, an ExamplePrognoser was registered with the
theprognosersandcommunicators,thesecondlayerofcon- name “example”. Now, if users were to specify to use the
figuration files from Figure 7. For each configuration file prognoser“example”inthetypefield(i.e.type:example)
specifiedtheProgManagerwouldcreateanewprognoseror oftheprognoserconfigurationfile,anExamplePrognoserwill
communicator and configure it to the parameters in its re- be created. This is one example, but the same can be done
spectiveconfigurationfile.Theconfigurationparameterscur- with the CommunicatorFactor, ModelFactory, ObserverFac-
rentlysupportedatthetoplevelarelistedinTable4. tory,andPredictorFactory.
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 9
INTERNATIONALJOURNALOFPROGNOSTICSANDHEALTHMANAGEMENT
Table5. ModelBasedPrognoserConfigurationParameters
PrognoserFactory & progFactory =
PrognoserFactory::instance();
Key Description
progFactory.Register("example",
PrognoserFactory::Create<ExamplePrognoser>); model NameofModel
observer NameofObserver
predictor NameofPredictor
Users can also add a search path for configuration files us-
Model.event Nameofsystemeventtopredict
ingtheaddSearchPathcommand,asshownbelow. Thiswill Predictor.numSamples Number of samples for predic-
allow configuration files to be specified by filename without tion
theirpath. Predictor.horizon Timehorizonofprediction
Model.predictedOutputsNamesofsystempredictedout-
ConfigMap::addSearchPath("../example/cfg/"); puts
inputs Names of system inputs from
sensors
GSAP will automatically log the steps being taken and any
outputs Names of system outputs from
errorstoalogfile. Theverbosityofthatloggingcanbedone
sensors
by setting the verbosity in the PAD (remember to include
"ThreadSafeLog.h"),asshowninthebelowexample.
Model
Logger::SetVerbosity(LEVEL) #numStates
#numInputs
#numOutputs
HereLEVELcanbereplacedwiththeleveloflogtoprint, +initialize(states, inputs, outputs)
+stateEqn(time, states, inputs, noise, step time)
rangingfromLOG TRACE (mostverbose)toLOG OFF +outputEqn(time, states, inputs, noise, output)
+transform(inputs, outputs) ConcreteModel
(no log kept). It is suggested that you keep the log at
LOG INFO,unlessyouareactivelydebuggingaproblem.
Note,thatthelogfilesizecangrowquicklyifkeptatahigh Figure8. ModelDesign
verbosity.
AnexampleofanemptyPADcanbefoundinAppendixA.6. 1. Retrieve the system inputs and outputs from the given
data.
5.4.3. Extending
2. Runastepoftheobserver,giventheinputsandoutputs.
Newprognosersandcommunicatorscanbeaddedtoextend 3. Retrievetheupdatedstateestimatefromtheobserver.
the capabilities of GSAP. This is done using the interfaces
4. Runastepofthepredictor,usingtheupdatedstateesti-
describedinSections5.2.1and5.2.3,respectively.
mateastheinitialcondition.
5.5. Model-basedPrognoser
The details of the components are described in detail in the
Acommonapproachtoprognosticsisthemodel-basedprog- followingsections.
nosticsparadigm(Orchard&Vachtsevanos, 2009; Daigle&
Goebel,2013;Saha&Goebel,2009),whereprognosisisper- 5.5.1. Model
formed using a combination of a state estimation algorithm
TheModelclassisessentiallyawrapperaroundadiscrete-
(often a Bayesian filter) and a prediction algorithm, both of
time dynamic system model. It defines the system states,
whichrelyonamodelofthemonitoredsystem. Becausethis
outputs, inputs, and specifies the interfaces for state update
is such a common approach, a ModelBasedPrognoser
equationandtheoutputequation.Asystemmodelcanbecre-
class, implementing the Prognoser interface, is provided
atedbyderivingfromthisabstractclassandimplementingthe
byGSAP.
stateandoutputequations,i.e.,Eq.2andEq.5,respectively.
A model-based prognoser contains three main objects: a
Foranexampleofanemptymodel,seeSectionA.3.
PrognosticsModel,anObserver,andaPredictor.
Thesealldefineinterfaces,andtheuserprovidesspecificin-
5.5.2. PrognosticsModel
stantiations of each of these, e.g., a battery model, an un-
scented Kalman filter (UKF), and a Monte Carlo-based pre- THe PrognosticsModel class extends the Model class
dictor. ItsconfigurationparametersaregiveninTable5. withthethresholdequation(Eq.1),thepredictedoutputequa-
tion(Eq.4),andaninputequation:
The step function of the prognoser performs the same ac-
tions,regardlessofthespecificcomponentsthatcomprisethe
u(k)=i(k,θ (k)), (6)
u
prognoser. Thus,auserneedsonlytoappropriatelyconfigure
theprognoseranddoesnotneedtowriteanynewcode. The whereiistheinputfunction,andθ (k)isasetof“inputpa-
u
stepfunctionperformsthefollowingactions: rameters”thatspecifyhowtodeterminetheinputsatagiven
InternationalJournalofPrognosticsandHealthManagement,ISSN2153-2648,2017 10