Patent Application
20230125616
Under modem computing workloads, a large amount of interaction is required between the various components of the computer systems, e.g., between modules of a System on a Chip (SoC) or between hardware components of a computer system. This brings increasing challenges for device manufacturers to ensure the system can proactively and consistently manage the state of its modules to meet the end-user expectations of the product.
Some examples of apparatuses and/or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which
Some examples are now described in more detail with reference to the enclosed figures. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not be restrictive of further possible examples.
Throughout the description of the figures same or similar reference numerals refer to same or similar elements and/or features, which may be identical or implemented in a modified form while providing the same or a similar function. The thickness of lines, layers and/or areas in the figures may also be exaggerated for clarification.
When two elements A and B are combined using an “or”, this is to be understood as disclosing all possible combinations, i.e., only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the same combinations, “at least one of A and B” or “A and/or B” may be used. This applies equivalently to combinations of more than two elements.
If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the same function. If a function is described below as implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. It is further understood that the terms “include”, “including”, “comprise” and/or “comprising”, when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and/or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and/or a group thereof.
In the following description, specific details are set forth, but examples of the technologies described herein may be practiced without these specific details. Well-known circuits, structures, and techniques have not been shown in detail to avoid obscuring an understanding of this description. “An example/example,” “various examples/examples,” “some examples/examples,” and the like may include features, structures, or characteristics, but not every example necessarily includes the particular features, structures, or characteristics.
Some examples may have some, all, or none of the features described for other examples. “First,” “second,” “third,” and the like describe a common element and indicate different instances of like elements being referred to. Such adjectives do not imply element item so described must be in a given sequence, either temporally or spatially, in ranking, or any other manner. “Connected” may indicate elements are in direct physical or electrical contact with each other and “coupled” may indicate elements co-operate or interact with each other, but they may or may not be in direct physical or electrical contact.
As used herein, the terms “operating”, “executing”, or “running” as they pertain to software or firmware in relation to a system, device, platform, or resource are used interchangeably and can refer to software or firmware stored in one or more computer-readable storage media accessible by the system, device, platform, or resource, even though the instructions contained in the software or firmware are not actively being executed by the system, device, platform, or resource.
The description may use the phrases “in an example/example,” “in examples/examples,” “in some examples/examples,” and/or “in various examples/examples,” each of which may refer to one or more of the same or different examples. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to examples of the present disclosure, are synonymous.
The processing circuitry 14 or means for processing 14 is to obtain information on an expected system configuration of the computer system 100 from the protected storage 101 of the computer system. The processing circuitry 14 or means for processing 14 is to determine information on a current system configuration of the computer system. The processing circuitry 14 or means for processing 14 is to compare the expected system configuration with the current system configuration. The processing circuitry 14 or means for processing 14 is to provide information on a mismatch via the output device 105 of the computer system if there is a mismatch between the expected system configuration and the current system configuration.
In the following, the functionality of the apparatus 10, the device 10, the method and of a corresponding computer program is illustrated with respect to the apparatus 10. Features introduced in connection with the apparatus 10 may likewise be included in the corresponding device 10, method and computer program.
The present disclosure relates to a concept for determining and handling a mismatch between an expected and a current system configuration. In the proposed concept, a reference state of the system configuration is defined and used as a point of comparison during operation of the computer system, to be compared with the current state of the system configuration. In this context, the system configuration may relate to various aspects of the computer system. In particular, the system configuration may relate to a hardware configuration of the computer system. Accordingly, the information on the expected system configuration may comprise information on an expected hardware configuration of the computer system, e.g., with respect to hardware components present within the computer system. For example, the information on the expected system configuration may comprise a representation of an enumeration of hardware components present in the computer system (e.g., of Advanced Configuration and Power Interface (ACPI) namespace objects representing hardware components, or of a corresponding device tree). In addition, the information on the expected system configuration may comprise information on a driver and/or a firmware being used to operate the respective hardware components. In other words, the information on the expected system configuration may comprise information on driver versions and/or firmware versions being used to operate the hardware components of the computer system.
In the present context, the term “hardware components of the computer system” is being used. This means that the proposed concept, at least primarily relates, to hardware components that are internal to the computer system, such as hardware components of the System on a Chip of the computer system, one or more hardware components that are hosted by a mainboard of the computer system, a processor of the computer system, Random Access Memory of the computer system, (flash) storage of the computer system, one or more non-hot-pluggable extension cards of the computer system etc. In other words, the expected (and also current) system configuration relate to internal components of the computer system, i.e., to non-peripheral components of the computer system. Peripheral components, such as external input devices, thumb drives or port extension docks may be omitted from the system configuration.
The collection of information about the system configuration is known from other concepts as “telemetry”, i.e., remote measurements, as the system configuration is, in these other concepts, merely collected locally, but evaluated centrally. For example, such telemetry is used in device management platforms, which are primarily used in professional contexts, such as large companies, but also in educational context, to manage a large fleet of devices, and in particular computer systems. In the present concept, a different approach is chosen -in the present concept, the respective information on the system configuration is used and collected locally, e.g., without transmitting said information to a server for a centralized administration of the computer system. Nonetheless, as the term is widely used in the field, the respective information on the system configuration may be denoted telemetry data. In other words, the information on the expected system configuration and the information on the current system configuration may comprise telemetry data.
The proposed concept is centered around the information on the expected system configuration of the computer system 100. In the context of
As outlined above, the information on the expected configuration of the may be static or quasi-static information, i.e., information that is never or only occasionally overwritten (depending on implementation). For example, if the information on the expected system configuration only relates to the hardware components present within the computer system, the information on the expected system configuration might never be changed as, in most computer systems, the hardware does not change over the lifetime of the computer system. For example, the expected system configuration may be a factory-defined system configuration of the computer system. In these cases, the information on the expected system configuration might only be overwritten in case of a repair or an upgrade of the computer system, e.g., when a removable component is replaced or added to the computer system in the field (e.g., a RAM upgrade, installation of wireless card etc.). Thus, an administrator of the computer system may be allowed to modify the information on the expected system configuration in such an event. In another scenario, such a modification may be performed more often. This is the case if the information on the expected system configuration also comprises information on the driver or firmware versions being used to operate the respective hardware components, more frequent updates to the information on the expected system configuration may be applied, e.g., after the new driver or firmware version has proven to be stable. In both cases, the expected system configuration may be a factory-defined system configuration of the computer system that is modifiable by an administrator of the computer system, e.g., after an upgrade or repair of a hardware component of the computer system, after installing a new removable component, or after updating a driver of firmware of a hardware component.
During the lifetime, the expected system configuration is compared with the current system configuration (which is also denoted secondary telemetry data in connection with
While the information on the expected system configuration may initially be compiled in the factory (or during configuration) of the computer system, the information on the current system configuration may be determined anew (e.g., from scratch, or at least partially from scratch) at various points during the lifetime of the computer system. In general, errors often occur during transitions between different states, e.g., when the computer system wakes from sleep, or after the computer system cold boots. Accordingly, the processing circuitry may determine the information on the current system configuration after a power state transition of the computer system. In this context, the power state may correspond to the power states as defined in the ACPI, e.g., from S0 (active/working) to S5 (soft off), or from G0 (active/working) to G3 (mechanical off), via different sleep states (G1, S0ix-S4) and the soft-off state (G2, S5). In other words, the transition may occur between soft off, sleeping and active, of between the different states (e.g., from S5 (soft-off) to S0 (active), or S3 (sleep, suspend to RAM) to S0 (active), or from S1 (power on suspend) to S0 (active)). In particular, the processing circuitry may determine the information on the current system configuration after the computer system transitions from a sleep state (or soft-off state) to an active state. Another type of power state transition occurs when the computer system is cold-booted. For example, the processing circuitry may determine the information on the current system configuration after or during a boot process of the computer system. Alternatively, or additionally, the information on the current system configuration may be updated at regular intervals (e.g., hourly, or daily). In other words, the processing circuitry may determine the information on the current system configuration according to a pre-defined schedule. As a final option, the information on the current system configuration may be determined after an error occurs (e.g., after a crash of the system).
As the determination of the information on the current system configuration has a non-negligible overhead, the collection of the information may be foregone if it would (severely) negatively impact the operation of the computer system. For example, if the computer system is a laptop computer (or another battery-powered device, such as a tablet computer or a smartphone), the determination of the information on the current system configuration may be foregone if the computer system is operating on battery power, or if the charging level is below a threshold. In other words, the processing circuitry may determine the information on the current system configuration when a power condition is met, e.g., if the computer system is not operating on battery power/being supplied by an external power supply, or if the charging level is above or at least the threshold.
To determine the information on the current system configuration, various sources within the computer system may be queried. For example, to obtain the hardware components being enumerated by the computer system (e.g., by the system firmware, via the ACPI), the system firmware may be queried. In other words, the processing circuitry may determine the information on the current system configuration by querying the system firmware 102 of the computer system. Another source is the kernel of the operating system. For example, hardware components being enumerated by the computer system may be determined via the operating system, e.g., by querying the list of active hardware components being enumerated by the kernel of the operating system. The kernel of the operation system may also be queried to determine the driver versions being used to operate the hardware components. In other words, the processing circuitry may determine the information on the current system configuration by querying the kernel of the operating system of the computer system. Additionally, or alternatively, based on the information on the expected system configuration, the respective hardware components may be queried individually. The latter may also be done to obtain information on a firmware version being used to operate the respective hardware components. In other words, the processing circuitry may determine the information on the current system configuration by querying a hardware component 103, i.e., the respective hardware component, of the computer system. This may be done directly, or via the respective driver being used to operate the hardware component. Accordingly, the processing circuitry may determine the information on the current system configuration by querying a driver of a hardware component 103 of the computer system, which may also be used to determine the version of the driver. In some cases, multiple hardware components are being managed by an intermediate entity, such as an embedded controller (i.e., a controller that is embedded in the computer system). Accordingly, the processing circuitry may determine the information on the current system configuration by the embedded controller 104 of the computer system. In summary, and with respect to the corresponding method, as further shown in
Once the information on the expected system configuration is obtained (e.g., read-out) from the protected storage and the information on the current system configuration is determined, the two may be compared (as they contain “comparable” information). In particular, during comparison of the two, mismatches may be detected and used to trigger one or more subsequent operations. In particular, in many cases, a mismatch does not necessarily have a large impact, in particular if driver versions and/or firmware versions are also compared. Therefore, the likely (i.e., projected, predicted) impact of the mismatch may be determined in a first operation. For example, the processing circuitry may determine, based on a data storage with known impacts (which may be stored in the storage circuitry 16), information on a likely impact of the mismatch. Accordingly, as further shown in
In many cases, knowledge may be compiled on how to deal with various types of mismatches. For example, some types of mismatches (such as a hardware component not being included in the current system configuration, but in the expected system configuration) may be addressed (in an attempt to correct the mismatch) by hard-resetting the hardware component or by rebooting the computer. Other types of mismatch (e.g., a driver or firmware version mismatch that temporally coincides with a crash) may be addressed by restoring the driver version or firmware version to a previous state (if possible). The processing circuitry may determine, based on a data storage with proposed mitigations (which may be stored in the storage circuitry 16), information on a proposed mitigation for mitigating the mismatch. Accordingly, as further shown in
If a mismatch is detected (and is judged to have a large, or at least moderate impact), a user of the computer system is notified of the mismatch. In particular, the processing circuitry is to provide information on the mismatch via an output device 105 of the computer system if there is a mismatch between the expected system configuration and the current system configuration. For example, the processing circuitry may provide the information on the mismatch via a display of the computer system, e.g., as a notification, via a notification facility of the operating system of the computer system. Additionally, or alternatively, an alert may be played via a speaker of the computer system. The information on the mismatch may include various pieces of information, e.g., information on the mismatch having occurred (e.g., a representation of the respective configuration portions included in the expected and current configuration), information on the likely impact with the information on the mismatch, and/or information on the proposed mitigation with the information on the mismatch. For example, the user may be provided with an option to ignore the mismatch, to manually take corrective action (e.g., by rebooting the computer system or reinstalling an earlier driver), or to automatically (i.e., controlled by the proposed apparatus, device, method, or computer program) take corrective action (e.g., by automatically rebooting the computer system, by resetting a hardware component, or by automatically reverting to an older driver version or older firmware version).
As outlined above, not every mismatch may be worth notifying the user. In particular, if a driver or firmware is updated, and no crash occurs, no notification may be necessary. In other cases, e.g., cases with a large impact, the information on the mismatch may be provided. For example, the information on the mismatch may be provided in at least one of the following cases if a hardware component is present in the expected configuration and missing in the current configuration, if a hardware component is missing in the expected configuration and present in the current configuration, if a hardware component has a different configuration between the expected configuration and the expected configuration, and if a driver or firmware version is different and a crash has occurred in temporal coincidence with the update to the driver or firmware version.
As outlined above, in some cases, it may be beneficial to update the (quasi-static) information on the expected system configuration. This may be the case if hardware is replaced or added to the computer system, of if a driver or firmware is updated and is proven to be working well. In these cases, an update may be applied. For example, the processing circuitry may detect a change in the system configuration of the computer system, authenticate an administrator of the computer system, and overwrite the expected system configuration based on the detected change in the system configuration and based on the authentication of the administrator of the computer system. Accordingly, as further shown in
The interface circuitry 12 or means for communicating 12 may correspond to one or more inputs and/or outputs for receiving and/or transmitting information, which may be in digital (bit) values according to a specified code, within a module, between modules or between modules of different entities. For example, the interface circuitry 12 or means for communicating 12 may comprise circuitry configured to receive and/or transmit information.
For example, the processing circuitry 14 or means for processing 14 may be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer or a programmable hardware component being operable with accordingly adapted software. In other words, the described function of the processing circuitry 14 or means for processing may as well be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components may comprise a general-purpose processor, a Digital Signal Processor (DSP), a micro-controller, etc.
For example, the storage circuitry 16 or means for storing information 16 may comprise at least one element of the group of a computer readable storage medium, such as a magnetic or optical storage medium, e.g., a hard disk drive, a flash memory, Floppy-Disk, Random Access Memory (RAM), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), an Electronically Erasable Programmable Read Only Memory (EEPROM), or a network storage.
For example, the computer system 100 may be desktop computer, a laptop computer, a tablet computer, a server computer, or a mobile device, such as a smartphone.
More details and aspects of the apparatus, device, method, computer program and computer system are mentioned in connection with the proposed concept, or one or more examples described above or below (e.g.,
Various examples of the present disclosure relate to a concept for defining a software-readable expected system configuration. For example, the software-readable “expected system configuration” may be defined at time of manufacture and/or time of boot. Higher order software (e.g., (Basic Input/Output Software, a system firmware implementation), OS (Operating System), Applications) can compare against the observed configuration. This may allow the higher-order software to discover discrepancies between the intended / expected configuration and the actual configuration. For example, a missing or non-enumerated USB (Universal Serial Bus) end-point may be discovered through this discrepancy. The utility of the proposed concept invention may apply from early manufacturing validation (e.g. Processor Platform Validation, PPV) through to end-user system use.
Client devices, such as the computer system introduced in connection with
The present disclosure proposes for providing secured and trusted read-only and readable telemetry data of system configuration that may be used to help identify components and services which are in undesired state in a computing system.
The proposed concept may leverage dynamically collected Telemetry data of expected device configuration (e.g., the information on the expected system configuration) for key product requirements and specifications while taking user privacy into consideration, working in tandem with hardware and OS to probe the enumeration information and state of on-device components/drivers/modules to ensure and highlight any footprint of uninitialized or undesired/bad state of modules which potentially impact boot time, runtime functionality, overall system performance and power consumption during usages of client device, thus providing better user experience.
The proposed concept may perform analysis of telemetry data of device configuration on the client device itself with a prestored invariant manifest telemetry data (i.e., the information on the expected hardware configuration). This disclosure might not propose an end user tool, but rather means to provide real-time feedback to an end user about potential issues in the device that are expected to be part of platform accessible via Advanced Configuration and Power Interface (ACPI) framework.
There may be a huge demand to have consistently highly scalable compute performance and power-efficient code to execute on client computing devices across its usages throughout the lifetime and power state transitions, with expectation of maintaining optimum power and performance for all user workloads. To meet these requirements on a client device, there are diverse architectural implementations of Central Processor Unit (CPU), Graphics Processing Unit (GPU), Audio/Video accelerators and Artificial Intelligence (AI) engines.
These System on a Chip (SoC) components use software components such as dedicated firmware, kernel threads/processes, OS (Operating System) threads, device drivers, software libraries, daemon services and user space applications to perform their tasks. These software modules each have their own lifecycle of loading, initializing, binding, running, interrupted state, sleeping state, stopped state, zombie, unbinding, unloading, register, unregister, cleanup, removing and such.
The proposed concept provides a mechanism for ensuring that, after auto-updates or power state transitions during normal usage, the end-user is notified of any unexpected outage of modules, services or components even if they are not under use. Any unexpected behavior resulting from faulty hardware components and incorrect states of software components on client device can create a bad user experience due to a lack of feedback mechanism.
In an OS which supports auto-update, the root file system may be mounted as read-only, and the device state may be stored on a read-write partition. This allows clear sandboxing of auto-updatable system OS and its components; and user data which does not get affected with auto-updates. In case of failure of the auto-update, such partitioning also allows device to fall back to last working state.
In the following, an imaginary scenario in the client device ecosystem is detailed, which may be observed when the client device is under use. For example, a client device may have a touchscreen and an onboard keyboard, which must be in working condition all the time. With an auto-update patch for the touchscreen and onboard keyboard driver that is not tested thoroughly, the touchscreen and onboard keyboard functionality may stop working (in the imaginary scenario). End-users might be aware of this potential issue only after the end user tries to perform interaction with client device using the touchscreen or onboard keyboard.
In another imaginary scenario, after a power state transition between cold boot, sleep or idle, the Bluetooth® driver might not be initialized successfully. Hence, when the end user of the client device is attempting to pairing a Bluetooth device during the conference call, the Bluetooth device might not pair with the client device.
Even if a desired component is enabled, a client device may be required to consistently meet local regulatory restrictions. For example, some countries do not allow 6 GHz band for Wi-Fi 802.11ax. In another example, there are operating constraints for power dissipation for a battery.
In other imaginary scenarios, external peripherals might be connected and yet not detected after power state transitions. For example, an external Thunderbolt™ dock may be connected, and then user puts device to sleep. After resuming the device, the Thunderbolt™ dock might not be detected.
In the existing client systems, telemetry data of device configuration is generally collected to understand user behavior (or platform hardware details) and is sent to a server to analyze it further for future usage. This creates added network traffic. Thus, client users may disable such data collection to avoid burdening the network. In these cases, there generally is no data analysis being done locally on the health and life cycle of the device. Moreover, the knowledge being gained might not be used to help improve the user experience and platform performance. Thus, in theses cases, there may be lack of actions taken upon collection of the telemetry data of device configuration with the purpose of improving system health and life cycle, leading to inefficient usage of platform resource and user experience.
The proposed concept may provide a mechanism to discover the ‘expected system configuration’ as a baseline to subsequently compare against the actual observed configuration (i.e., the current system configuration discussed in connection with
Due to advancements of technology with multiple capabilities in client systems, more automated solutions may include self-sustained remote capability in the client platform to assist users to overcome errors, especially when the system is not connected to a network. In many cases, the client systems do not have the localized capability to notify the user and fix the issues in advance before the user uses a module/hardware. This lack of automated approaches is especially troublesome for technical users as well as non-professional usages. Thus, there may be a lack of methodology to manage the endpoint device efficiently at a managed stage where better efficiency and lesser turnaround is desired to avoid having an inefficient usage of platform resources and impact on user experience.
The proposed concept is going beyond the commonly implemented usages of Telemetry data, where enterprise administrators collect telemetry data from enterprise-enrolled devices, with the transmitted telemetry data being used, by enterprise administrators, to enforce policies, install OS update and extensions, or notify users to correct the behavior of usages. Other Telemetry concepts provided by Original Equipment Manufacturers (OEMs) and Independent Software Vendors (ISVs) are mostly enterprise-oriented and consist of collecting user activities, behavior, and habit information for personalizing the apps / devices. They also include collecting statistical data, identifying vulnerabilities or anomalies, and, based on the collected data, automatically or conditionally pushing auto-updates, upgrading system packages and/pr components. Other concepts may also discuss secure ways for performing over-the-air updates, finding anomalies, and analyzing for correlation with recent updates. If an anomaly is related to an update, source code files (or components) linked to the update may be found, and a User Interface (UI) may be provided for accessing correlated updates or source code files, and for communicate with update controller. For example, in a telemetry product that is specific to Chromebooks, an enterprise administrator collects the data through Google Cloud, which is used for enforcing policies, installing OS update sand extensions, or notifying users to correct usage behaviors.
However, existing telemetry products are mostly or entirely limited to enterprise devices. In these products, data is given to the administrator and not to the actual end users, who then take proper actions. Generally, personal devices do not have a way of knowing the health state of the device after updates/power state transitions. Its lack of self-awareness before executing remote provisioning or Intel® vPro® based manage options on enterprise laptops results in users being unaware of the potential issue. Most of the time when an issue occurs during update/power state transitions, subsystems of client device do not count consistently as per platform specifications, which may lead to an ineffective use of system resources and a bad user experience.
The proposed concept may provide an approach for finding static telemetry data and locally leveraging telemetry data of the device configuration to provide enhancements to the end user about the status and/or health of different underlying platform hardware, modules and/or components.
In the proposed concept, initial manifest Telemetry data of device configuration (i.e., the information on the expected system configuration) is pre-installed in a read-only memory (i.e., the protected storage) (can be called as primary copy), e.g., once the System Under Test (SUT) completes the power state transitions. This read-only copy of telemetry data can be treated as invariant data and may be always static. Read-only telemetry may be used for localized dynamic comparison against Telemetry data of device configuration (i.e., the information on the current system configuration) saved during normal usages in Read-Write region (can be called as secondary copy). The proposed concept may be invoked after a platform upgrade to identify potential issues arising from this comparison. It may notify in the notification area and suggestion/options to the end user, for resolving the potential issue with possible resolution.
As the proposed concept is implemented in client device itself, the following parameters may provide additional benefit compared to other, cloud-based telemetry products as shown in
The proposed concept may avoid critical bottleneck scenarios with and without remote system management. In the proposed concept, first, Telemetry data of the device configuration is stored as read-only. This data remains static and invariant. Then, the concept dynamically queries Telemetry data of device configuration (i.e., the information on the current system configuration) and detect (any) deviations that may impact end user experience, the power envelope and/or the security of the device. The transitions used in the proposed concept are localized in nature. As there is no data exchange between a client and a telemetry server, privacy may be ensured. The proposed concept may be used to dynamically detect deviations from product requirements and to make remote manageability more effective. The proposed concept may also be used to help in dynamic detection of deviations from recommended security policies for the device, providing appropriate action in form of a notification. The proposed concept may effectively manage the system power envelop with this on-device detection process continuing to use client device in undesired state.
In various examples, the proposed concept requires no structural/hardware design change in the client computing device. As a result, there might not be a Bill of Materials (BOM) component added. The proposed concept may be used to provide the current health of the client device, showing status of (all of) the modules. For sake of privacy and security, user consent may be obtained once end-user reads End User License Agreement (EULA).
The proposed concept uses a primary and a secondary telemetry data copy.
As shown in
As further shown in
Data Collection and Analytics (DCA) is an Intel-developed capability to efficiently gather, analyze and use data for fleet intelligence. Distinguishing features of DCA vs. other telemetry frameworks are explicit initial user consent for privacy and security, low performance overhead (estimated to be <0.5% of CPU), portability across stack from Internet of Things (IOT) devices to client devices to the data center and cross OS support for Windows & Linux. It may support expandable collection, as the collector is modular and additional collection & analysis modules, detailed below, to allow customers to collect and interpret specific system information and usage metrics.
In a specific implementation of the proposed concept, the telemetry daemon 324 leverages the Intel Data Collection and Analytics (DCA) framework to maintain the primary telemetry data copy 321 of the device configuration (as read-only) and the secondary telemetry data copy 322 of the device configuration (as read/write). The intention of the telemetry daemon 324 may be to detect problems, predict impacts and provide information to users for corrective actions. The scope of this daemon may be to detect software-detectable errors. For example, a specific device driver not being functional after certain events like system restart, system resume from sleep or OS patch upgrade - here, the daemon may also help to compare the impact of non-functional/faulty device to end user in the notification area.
As shown in
In the following, some possible outcomes of comparing the primary copy (read-only) and the secondary copy (read-write) are given. If the primary copy not present, the end-user may be informed, and the software support system may be informed through an OS feedback mechanism or SUT feedback mechanism. Users may be allowed to mask the notification temporarily or permanently. If the secondary copy is not present, the end-user may be informed, as this may relate to a potential issue, so workable solutions may be provided. The software support system may be informed through the OS feedback mechanism or SUT feedback mechanism. Users may be allowed to mask the notification temporarily or permanently. If the primary copy is the same as the secondary copy, no action might be taken. If items are missing in the primary copy, but present in the secondary copy (e.g., in the audio device tree), the end-user may be informed, and the software support system may be informed through the OS feedback mechanism or SUT feedback mechanism. Users may be allowed to mask the notification temporarily or permanently. If items are missing in the secondary copy, but present in primary copy (e.g., within the audio device tree), the end-user may be informed, as this may relate to a potential issue, so workable solutions may be provided. The software support system may be informed through the OS feedback mechanism or SUT feedback mechanism. Users may be allowed to mask the notification temporarily or permanently. If there is an items mismatch between the primary copy and the secondary copy (e.g., relating to the 3.5 mm audio device node), the end-user may be informed as this may relate to a potential issue, so workable solutions may be provided. The software support system may be informed through the OS feedback mechanism or SUT feedback mechanism. Users may be allowed to mask the notification temporarily or permanently.
The daemon may have one or more of the following user configuration options, which may improve the overall concept to be highly flexible. For example, for the sake of privacy and security, user consent may be obtained, once end-user reads the EULA. The user may have the option of completely enabling or disabling the daemon (enabling may help user make use of the proposed concept, while disabling daemon may disable the proposed concept). An option may be given to run daemon execution in battery-charging mode (Alternating Current, AC mode) only or battery-only mode (Direct Current, DC, mode), or both AC and DC mode (with the flexibility to run the daemon based on needs/system resource conservation). The user may have the option to generate and compare telemetry data after specific triggers/events, e.g., user can select when to do telemetry data comparisons e.g., after a restart, after resume from sleep, after resume from hibernate, after an auto-update (OS/driver patches) or after any system crash/hangs/recovery. User can select all or a subset of triggers/events. The daemon may categorize the issues based on the criticality and notify the end user accordingly, whereby the end user can take the action based on the priority of the issue.
Telemetry data may be captured from the hardware platform for power (CPU, system memory etc.), performance (CPU, cache memory etc.), thermal, Peripheral Component Interconnect Express (PCIe) interfaces etc. Telemetry data may be captured using Intel Data Collection and Analytics (DCA) capability, with aid of model-specific registers (MSRs) and existing onboard sensors. This may help to obtain a negligible perceived latency and negligible CPU load. The proposed concept might not collect any personally identifiable information such as name, email address, IP address, MAC address, user details. The proposed algorithm of efficient endpoint manageability can be performed inside AI (Artificial Intelligence) solutions that can be integrated into Intel® Architecture (IA) SoC and may be an effective approach across various platforms without any changes in system BIOS or OS infrastructure.
End users may obtain the information about the issue showing the criticality of the issue in the client device early in the notification area. The user can then selectively choose what corrective actions are to be performed based on the criticality of the issue. Using the proposed concept, a suitable or best approach for dealing with each of the unique issues the device has gone through may be provided, along with the following advantages. For example, the user may be notified of (all of) the possible discrepancies in an OS supplied notification area. A suitable or best approach for dealing with the underlying issue is suggested, which the user can start by interacting with the user space application. For example, recommendations may be tailored to platform under use. The proposed concept may suggest reverting to a previous known/working OS, when the components after software update shows anomalies, which may be an early indicator of points of component/system failure.
More details and aspects of the concept for defining a software-readable expected system configuration are mentioned in connection with the proposed concept or one or more examples described above or below (e.g.,
In the following, some examples of the proposed concept are presented:
An example (e.g., example 1) relates to an apparatus (10) for a computer system (100), the apparatus comprising interface circuitry (12), machine-readable instructions and processing circuitry (14) to execute the machine-readable instructions to obtain information on an expected system configuration of the computer system (100) from a protected storage (101) of the computer system. The machine-readable instructions comprise instructions to determine information on a current system configuration of the computer system. The machine-readable instructions comprise instructions to compare the expected system configuration with the current system configuration. The machine-readable instructions comprise instructions to provide information on a mismatch via an output device (105) of the computer system if there is a mismatch between the expected system configuration and the current system configuration.
Another example (e.g., example 2) relates to a previously described example (e.g., example 1) or to any of the examples described herein, further comprising that the machine-readable instructions comprise instructions to determine the information on the current system configuration after a power state transition of the computer system.
Another example (e.g., example 3) relates to a previously described example (e.g., example 2) or to any of the examples described herein, further comprising that the machine-readable instructions comprise instructions to determine the information on the current system configuration after the computer system transitions from a sleep state to an active state.
Another example (e.g., example 4) relates to a previously described example (e.g., one of the examples 2 to 3) or to any of the examples described herein, further comprising that the machine-readable instructions comprise instructions to determine the information on the current system configuration after or during a boot process of the computer system.
Another example (e.g., example 5) relates to a previously described example (e.g., one of the examples 1 to 4) or to any of the examples described herein, further comprising that the machine-readable instructions comprise instructions to determine the information on the current system configuration according to a pre-defined schedule.
Another example (e.g., example 6) relates to a previously described example (e.g., one of the examples 1 to 5) or to any of the examples described herein, further comprising that the machine-readable instructions comprise instructions to determine the information on the current system configuration when a power condition is met.
An example (e.g., example 7) relates to a The apparatus according to one of the examples 1 to 6, wherein the machine-readable instructions comprise instructions to determine the information on the current system configuration by querying at least one of a system firmware (102) of the computer system, a hardware component (103) of the computer system, an embedded controller (104) of the computer system, a kernel of an operating system of the computer system and a driver of a hardware component (103) of the computer system.
Another example (e.g., example 8) relates to a previously described example (e.g., one of the examples 1 to 7) or to any of the examples described herein, further comprising that the information on the mismatch is provided in at least one of the following cases if a hardware component is present in the expected configuration and missing in the current configuration, if a hardware component is missing in the expected configuration and present in the current configuration, and if a hardware component has a different configuration between the expected configuration and the expected configuration.
Another example (e.g., example 9) relates to a previously described example (e.g., one of the examples 1 to 8) or to any of the examples described herein, further comprising that the machine-readable instructions comprise instructions to determine, based on a data storage with proposed mitigations, information on a proposed mitigation for mitigating the mismatch, and to include the information on the proposed mitigation with the information on the mismatch.
Another example (e.g., example 10) relates to a previously described example (e.g., one of the examples 1 to 9) or to any of the examples described herein, further comprising that the machine-readable instructions comprise instructions to determine, based on a data storage with known impacts, information on a likely impact of the mismatch, and to include the information on the likely impact with the information on the mismatch.
Another example (e.g., example 11) relates to a previously described example (e.g., one of the examples 1 to 10) or to any of the examples described herein, further comprising that the expected and current system configuration relate to internal components of the computer system.
Another example (e.g., example 12) relates to a previously described example (e.g., one of the examples 1 to 11) or to any of the examples described herein, further comprising that the expected and current system configuration relate to non-peripheral components of the computer system.
Another example (e.g., example 13) relates to a previously described example (e.g., one of the examples 1 to 12) or to any of the examples described herein, further comprising that the information on the expected system configuration and the information on the current system configuration comprise telemetry data.
Another example (e.g., example 14) relates to a previously described example (e.g., one of the examples 1 to 13) or to any of the examples described herein, further comprising that the expected system configuration is a factory-defined system configuration of the computer system.
Another example (e.g., example 15) relates to a previously described example (e.g., one of the examples 1 to 14) or to any of the examples described herein, further comprising that the protected storage (101) is a read-only storage of the computer system.
Another example (e.g., example 16) relates to a previously described example (e.g., one of the examples 1 to 15) or to any of the examples described herein, further comprising that the expected system configuration is a factory-defined system configuration of the computer system that is modifiable by an administrator of the computer system.
Another example (e.g., example 17) relates to a previously described example (e.g., example 16) or to any of the examples described herein, further comprising that the protected storage (101) is a storage that is overwritable by an administrator of the computer system.
Another example (e.g., example 18) relates to a previously described example (e.g., one of the examples 16 to 17) or to any of the examples described herein, further comprising that the machine-readable instructions comprise instructions to detect a change in the system configuration of the computer system, authenticate an administrator of the computer system, and overwrite the expected system configuration based on the detected change in the system configuration and based on the authentication of the administrator of the computer system.
An example (e.g., example 19) relates to an apparatus (10) for a computer system (100), the apparatus comprising processing circuitry (14) to obtain information on an expected system configuration of the computer system (100) from a protected storage (101) of the computer system. The processing circuitry is to determine information on a current system configuration of the computer system. The processing circuitry is to compare the expected system configuration with the current system configuration. The processing circuitry is to provide information on a mismatch via an output device of the computer system if there is a mismatch between the expected system configuration and the current system configuration.
An example (e.g., example 20) relates to a device (10) for a computer system (100), the device comprising means for processing (14) for obtaining information on an expected system configuration of the computer system (100) from a protected storage (101) of the computer system. The means for processing is for determining information on a current system configuration of the computer system. The means for processing is for comparing the expected system configuration with the current system configuration. The means for processing is for providing information on a mismatch via an output device of the computer system if there is a mismatch between the expected system configuration and the current system configuration.
An example (e.g., example 21) relates to a method for a computer system (100), the method comprising obtaining (110) information on an expected system configuration of the computer system (100) from a protected storage (101) of the computer system. The method comprises determining (120) information on a current system configuration of the computer system. The method comprises comparing (130) the expected system configuration with the current system configuration. The method comprises providing (160) information on a mismatch via an output device of the computer system if there is a mismatch between the expected system configuration and the current system configuration.
Another example (e.g., example 22) relates to a previously described example (e.g., example 21) or to any of the examples described herein, further comprising that the method comprises determining (120) the information on the current system configuration after a power state transition of the computer system.
Another example (e.g., example 23) relates to a previously described example (e.g., example 22) or to any of the examples described herein, further comprising that the method comprises determining (120) the information on the current system configuration after the computer system transitions from a sleep state to an active state.
Another example (e.g., example 24) relates to a previously described example (e.g., one of the examples 22 to 23) or to any of the examples described herein, further comprising that the method comprises determining (120) the information on the current system configuration after or during a boot process of the computer system.
Another example (e.g., example 25) relates to a previously described example (e.g., one of the examples 21 to 24) or to any of the examples described herein, further comprising that the method comprises determining (120) the information on the current system configuration according to a pre-defined schedule.
Another example (e.g., example 26) relates to a previously described example (e.g., one of the examples 21 to 25) or to any of the examples described herein, further comprising that the method comprises determining (120) the information on the current system configuration when a power condition is met.
Another example (e.g., example 27) relates to a previously described example (e.g., one of the examples 21 to 26) or to any of the examples described herein, further comprising that the method comprises determining (120) the information on the current system configuration by querying (125) at least one of a system firmware (102) of the computer system, a hardware component (103) of the computer system, an embedded controller (104) of the computer system, a kernel of an operating system of the computer system and a driver of a hardware component (103) of the computer system.
Another example (e.g., example 28) relates to a previously described example (e.g., one of the examples 21 to 27) or to any of the examples described herein, further comprising that the method comprises determining (150), based on a data storage with proposed mitigations, information on a proposed mitigation for mitigating the mismatch, and to include the information on the proposed mitigation with the information on the mismatch.
Another example (e.g., example 29) relates to a previously described example (e.g., one of the examples 21 to 28) or to any of the examples described herein, further comprising that the method comprises determining (140), based on a data storage with known impacts, information on a likely impact of the mismatch, and to include the information on the likely impact with the information on the mismatch.
Another example (e.g., example 30) relates to a previously described example (e.g., one of the examples 21 to 29) or to any of the examples described herein, further comprising that the expected system configuration is a factory-defined system configuration of the computer system that is modifiable by an administrator of the computer system, and wherein the method comprises detecting (132) a change in the system configuration of the computer system, authenticate (136) an administrator of the computer system, and overwriting (136) the expected system configuration based on the detected change in the system configuration and based on the authentication of the administrator of the computer system.
An example (e.g., example 31) relates to a computer system comprising an apparatus or device according to one of the examples 1 to 20 (or according to any other example).
An example (e.g., example 32) relates to a computer system being configured to perform the method according to one of the examples 21 to 30 (or according to any other example).
An example (e.g., example 33) relates to a non-transitory machine-readable storage medium including program code, when executed, to cause a machine to perform the method of one of the examples 21 to 30 (or according to any other example).
An example (e.g., example 34) relates to a computer program having a program code for performing the method of one of the examples the method of one of the examples 21 to 30 (or according to any other example) when the computer program is executed on a computer, a processor, or a programmable hardware component.
An example (e.g., example 35) relates to a machine-readable storage including machine readable instructions, when executed, to implement a method or realize an apparatus as claimed in any pending claim or shown in any example.
The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.
Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor, or other programmable hardware component. Thus, steps, operations or processes of different ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and/or contain machine-executable, processor-executable or computer-executable programs and instructions. Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.
It is further understood that the disclosure of several steps, processes, operations, or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execution of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process or operation may include and/or be broken up into several sub-steps, -functions, -processes or -operations.
If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.
As used herein, the term “module” refers to logic that may be implemented in a hardware component or device, software or firmware running on a processing unit, or a combination thereof, to perform one or more operations consistent with the present disclosure. Software and firmware may be embodied as instructions and/or data stored on non-transitory computer-readable storage media. As used herein, the term “circuitry” can comprise, singly or in any combination, non-programmable (hardwired) circuitry, programmable circuitry such as processing units, state machine circuitry, and/or firmware that stores instructions executable by programmable circuitry. Modules described herein may, collectively or individually, be embodied as circuitry that forms a part of a computing system. Thus, any of the modules can be implemented as circuitry. A computing system referred to as being programmed to perform a method can be programmed to perform the method via software, hardware, firmware, or combinations thereof.
Any of the disclosed methods (or a portion thereof) can be implemented as computer-executable instructions or a computer program product. Such instructions can cause a computing system or one or more processing units capable of executing computer-executable instructions to perform any of the disclosed methods. As used herein, the term “computer” refers to any computing system or device described or mentioned herein. Thus, the term “computer-executable instruction” refers to instructions that can be executed by any computing system or device described or mentioned herein.
The computer-executable instructions can be part of, for example, an operating system of the computing system, an application stored locally to the computing system, or a remote application accessible to the computing system (e.g., via a web browser). Any of the methods described herein can be performed by computer-executable instructions performed by a single computing system or by one or more networked computing systems operating in a network environment. Computer-executable instructions and updates to the computer-executable instructions can be downloaded to a computing system from a remote server.
Further, it is to be understood that implementation of the disclosed technologies is not limited to any specific computer language or program. For instance, the disclosed technologies can be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, C#, assembly language, or any other programming language. Likewise, the disclosed technologies are not limited to any particular computer system or type of hardware.
Furthermore, any of the software-based examples (comprising, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, ultrasonic, and infrared communications), electronic communications, or other such communication means.
The disclosed methods, apparatuses, and systems are not to be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed examples, alone and in various combinations and subcombinations with one another. The disclosed methods, apparatuses, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed examples require that any one or more specific advantages be present or problems be solved.
Theories of operation, scientific principles, or other theoretical descriptions presented herein in reference to the apparatuses or methods of this disclosure have been provided for the purposes of better understanding and are not intended to be limiting in scope. The apparatuses and methods in the appended claims are not limited to those apparatuses and methods that function in the manner described by such theories of operation.
The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not intended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.
