Public Member Functions | Static Public Member Functions | Protected Member Functions | Static Protected Member Functions | Static Protected Attributes
MonitorEngine Class Reference

#include <monitoring.h>

List of all members.

Public Member Functions

bool validatePlan (std::vector< std::string > &plan)
bool validatePlan (const std::vector< std::vector< PlanStep > > &plan)
 Validate a plan.
bool validatePlanOld (const std::vector< std::vector< PlanStep > > &plan) __attribute__((deprecated))
 Old version - no idea how that works.
 ~MonitorEngine ()

Static Public Member Functions

static MonitorEnginegetInstance ()
static bool validatePlan (const string &filename)
 Static convenience function to validate the plan from this file.

Protected Member Functions

 MonitorEngine ()

Static Protected Member Functions

static void readPlanFromFile (const string &filename, vector< string > &plan)

Static Protected Attributes

static MonitorEngineinstance = 0

Detailed Description

Definition at line 71 of file monitoring.h.


Constructor & Destructor Documentation

Definition at line 55 of file monitoring.cpp.

Definition at line 59 of file monitoring.cpp.


Member Function Documentation

Definition at line 24 of file monitoring.cpp.

void MonitorEngine::readPlanFromFile ( const string &  filename,
vector< string > &  plan 
) [static, protected]

Definition at line 32 of file monitoring.cpp.

bool MonitorEngine::validatePlan ( const string &  filename) [static]

Static convenience function to validate the plan from this file.

Definition at line 44 of file monitoring.cpp.

bool MonitorEngine::validatePlan ( std::vector< std::string > &  plan)
bool MonitorEngine::validatePlan ( const std::vector< std::vector< PlanStep > > &  plan)

Validate a plan.

Verify a plan by simulating an execution. It can't be guaranteed that timestamps/durations are exactly matched in a real-world system. So the simulation will try to apply operators in the order induced by the start timestamps and an arbitrary number of let_time_passes. This multiple let_time_pass thus generate multiple traces/plans that only differ from the timestamps but have the same order. The queue in step i always stores a collection of the states from applying operators until step i and all combinations of let_time_pass used. After the last operator is applied the queue should contain at least one state that satisfies the goal check, i.e. the goal_state is satisfied and no running operators are left.

When applying same-time operators the plans order is used. If those operators were in conflict with each other (violating no-moving-targets-rule) they should have been epsilonized before (i.e. not the same timestamp). This means that any order should be applicable, just using the original one should thus always work.

Parameters:
[in]plana vector of the plan's actions. Each action can consist of >= 1 PlanStep, thus there is a vector of PlanStep for each action. The reason is that during grounding, one ground action might be split into multiple operators with the same name.

Definition at line 162 of file monitoring.cpp.

bool MonitorEngine::validatePlanOld ( const std::vector< std::vector< PlanStep > > &  plan)

Old version - no idea how that works.

Definition at line 275 of file monitoring.cpp.


Member Data Documentation

MonitorEngine * MonitorEngine::instance = 0 [static, protected]

Definition at line 75 of file monitoring.h.


The documentation for this class was generated from the following files:


tfd_modules
Author(s): Maintained by Christian Dornhege (see AUTHORS file).
autogenerated on Mon Oct 6 2014 07:52:06