Provided are methods of providing a virtual service that may provide partial real time service to clients of a production computing service that is unavailable. Methods may include generating, based on transaction data corresponding to a production computing service that is available, a production computing service model that includes multiple request types and multiple confidence values that correspond to ones of the request types. Methods may include responding to a request received from a client of the production computing service with a model-generated response to the request in response to the production computing service being unavailable. The production computing service is updated with the request received from the client and the model-generated response responsive to the production computing service being available after being unavailable.

A computing system for a secure and reliable firmware update through a verification process, dynamic validation and continuous monitoring for error or failure and speedy correction of Internet of Things (IoT) device operability. The invention uses a Trusted Execution Environment (TEE) for hardware-based isolation of the firmware update, validation and continuous monitoring services. The isolation is performed by hardware System on a Chip (SoC) Security Extensions such as ARM TrustZone or similar technologies on other hardware platforms. The invention therefore comprises Firmware Update Service (FUS), System Validation Service (SMS) and Continuous Monitoring Service (CMS) running in the TEE with dedicated memory and storage, thus providing a trusted configuration management functionality for the operating system (OS) code and applications on IoT devices.

Services running in the TEE use both direct (hardware level) and indirect (software agents inside main execution environment (MEE)) methods of control of the MEE. Embodiments of the invention apply all updates to a staging (new) execution environment (SEE) without changing of the MEE.

The present invention provides a method for accessing a flash memory module, wherein the flash memory module includes at least one flash memory chip, each flash memory chip includes a plurality of blocks, each clock includes a plurality of pages, and the method includes the steps of: providing a read-retry table, wherein the read-retry table includes a plurality of read setting levels, each read setting level corresponds to at least one read voltage, and no two read setting levels have the same read voltage; establishing a read success recording table, which records at least one specific read setting level that was previously used to successfully read the flash memory module; and when it is required to the read the flash memory module, using the at least one specific read setting level recorded in the read success recording table to read the flash memory module.

The invention is part of the field of computer technology. It describes the architecture of a secure automation system and a method for safe autonomous operation of a technical apparatus, in particular a motor vehicle. The architecture disclosed herein solves the problem that any Byzantine error in one of the complex subsystems of a distributed real-time computer system, regardless of whether the error was triggered by a random hardware failure, a design error in the software or an intrusion, must be recognized and controlled in such a way that no security-relevant incident occurs. The architecture includes four largely independent subsystems which are arranged hierarchically and each form an isolated Fault-Containment Unit (FCU). At the top of the hierarchy is a secure subsystem, which executes simple software on fault-tolerant hardware. The other three subsystems are insecure because they contain complex software executed on non-fault-tolerant hardware.

In some embodiments, a system is provided, comprising enforcement hardware configured to execute, at run time, a state machine in parallel with application code. Executing the state machine may include maintaining metadata that corresponds to one or more state variables of the state machine; matching instructions in the application code to transitions in the state machine; and, in response to determining that an instruction in the application code does not match any transition from a current state of the state machine, causing an error handling routine to be executed. In some embodiments, a description of a state machine may be translated into at least one policy to be enforced at run time based on metadata labels associated with application code and/or data manipulated by the application code.

Disclosed are various embodiments for workflow error handling for device driven management. A workflow can be received from a management service by a management agent. The workflow can define a sequence of actions to be implemented by the management agent on a client device and a set of error conditions associated with individual actions in the sequence of actions. The management agent can then process the individual actions in the sequence of actions defined by the workflow. Subsequently, the management agent can monitor the individual actions to determine whether the individual actions trigger an error condition in the set of error conditions. Finally, in response to a determination that the individual actions triggered the error condition in the set of error conditions, the management agent can perform an error response specified by the workflow.

Provided are a method, system, and computer program product in which a computational device stores a data structure that includes identifications of a plurality of volumes and identifications of one or more time locks associated with each of the plurality of volumes. The data structure is indexed into, to determine whether an input/output (I/O) operation from a host with respect to a volume is to be permitted.

A self-learning, self-healing database-management system determines that erroneous input, such as an improper SQL query, has caused a critical database condition. The system parses each input statement into a set of tokens, and then translates each set into lines of a failure script. The script is consolidated by cross-referencing each line to infer relationships between input statements. The system then searches historical database logs for previously entered, error-free input similar to the erroneous input. A degree of similarity between the erroneous input and each previously entered input is determined by a computational method that quantifies similarities between the failure script and each script generated from a previously entered input. The system revises the erroneous input to more closely match the most-similar previously entered input and resubmits the corrected input. The results of the resubmission are used to train the system to more accurately correct future input errors.

An information processing method includes performing a first boot operation, determining an execution time of the first boot operation and an execution time of a second boot operation before the first boot operation, in response to determining that an interval between the execution time of the first boot operation and the execution time of the second boot operation does not reach a first threshold, determining whether a call number of a first mirror image file before performing the first boot operation has reached a second threshold, and in response to determining that the call number of the first mirror image file before performing the first boot operation has not reached the second threshold, calling the first mirror image file.

A hierarchical high integrity system is disclosed. The system may include one or more operator input interfaces configured to receive one or more operator commands from an operator. The system may further include a hierarchy of a plurality of functional layers configured to perform one or more functions in response to the one or more operator commands. The hierarchy of the plurality of functional layers may include one or more upper functional layers and one or more lower functional layers. The one or more upper functional layers may configured to provide a greater level of automation than the one or more lower functional layers. Each functional layer may include a plurality of applications; an arbitrator configured to dynamically select the appropriate input source; an application selector configured to dynamically select an application; and a default safe fallback module configured to selectively provide a substantially safe operation for each functional layer.