Here are the answers to some frequently asked questions about BMC Helix AIOps

Service model

  1. A service is an identified set of functionalities that is provided from one organization to another or from one part of an organization to another part of the same organization. Services often come with associated service level agreements and other similar business characteristics. A service can be anything, such as the office cleaning service, but in this context, we are focused on computer-based services provided by IT departments and other cloud-based service providers.

  2. A business service is a service offered to end users or customers. Our customers use business services. For example, services such as Commodities Trading and Holiday Booking are used by internal users and Shopping Cart and Order History are used by external customers of a retail organization. In most cases, a single business service is used by many different users or customers. For example, there is only one Order History service for all customers globally or for a limited region, but there is certainly not one service per customer.

    A business application is a synonym for business service. It is also defined as a service offered to end users or customers. It can be used to represent a hierarchy in scenarios where an overall Service contains several distinct end-user Applications within it. For example, the Corporate Communication business service could be composed of Business Applications, such as Email, Instant Messaging, Video Conferencing and so on. Note that the Business Applications are end-user applications that non-technical users would recognize and not the underlying technical building blocks like databases, message buses, and web servers that they are built upon.

    A technical service is a service maintained by IT that provides shared functionality and is used by multiple business services. These are not the services or applications that end users see, but the infrastructure elements upon which the services are built and managed by groups within IT. For example, services such as Oracle Database Servers in London, Santa Clara Edge Switches, and Kubernetes Cluster ABC are technical services.

    A business service depends on facilities provided by the technical services, but not in a blanket manner. For example, many business services can make use of databases managed as part of the London Oracle Databases technical service. Suppose a database instance fails and needs a fix from the technical support team. The failure probably affects only one business service, not all the business services that use any of the other databases that are part of the same technical service. The nature of the business services affected are likely to have an influence on the priority of handling a failure. Fixing a database that is part of Commodities Trading is probably a higher priority than fixing one that is part of Holiday Booking.

    For more information, see Start anywhere modeling. Open link

  3. The BMC Helix Discovery taxonomy extension for Communication Service Providers (CSPs) adds two more types of services that are different from the IT-focused business and technical Services. The names and semantics of these are derived from the TM Forum Information Model (SID).

    A Customer Facing Service (CFS) is a service provided to a specific customer. If the CSP has 100 customers for a particular type of service, they have 100 Customer Facing Services, which uses different semantics compared to a business service in the IT space. A CFS can have a dedicated infrastructure, for example, a physical optic fiber. However, CFS is mainly important only from the billing and service level perspectives.

    A Resource Facing Service (RFS) is a service used internally to the CSP to support their CFS. It is often equivalent to either a business service or a technical service in the IT-focused model, but the CSP taxonomy includes RFS as a separate node kind for consistency with the TM Forum SID.

  4. In the BMC Helix ITOM solutions, BMC Helix Discovery stores an interconnected graph of nodes that represent computers, software, databases, network infrastructure, and so on, and the relationships between them. A service model in BMC Helix Discovery is a representation of all the nodes and relationships that are part of a particular service, and the service definition includes rules and configuration about how the service structure should be updated when the data changes.

    For more information on creating service models, see Building service models and Creating a model in BMC Helix Discovery. Open link

  5. The recommended dynamic changes interval is five minutes. However, it has been evaluated to work even at one minute interval with a limited data set.

  6. The knowledge graph contains domain-specific heuristics, such as types of anomalies and their causal relationships. It doesn't contain any runtime data or instances of CIs.

Service blueprint

  1. A service blueprint is a parameterized set of rules that identify the elements of a business service. It contains conditions for matching some starting nodes that should belong to a service and a set of graph traversals that are used to find related nodes.

    To use a blueprint to define a business service, you must create an instance of the blueprint by providing the input parameters to match the required nodes. The system can then use the traversal rules to find the matching related nodes and include them in the service. As the data changes, the system automatically re-applies the rules so that the service model stays up to date.

    For more information on creating service blueprints, see Creating service blueprints.

  2. As a consumer of service data in, there is no difference between BMC Helix AIOps service blueprint and BMC Helix Discovery SAAM, Users do not have to be concerned with which approach was used to define a model to be able to use it. There is a single back-end engine (part of the Discovery Reasoning Engine) that maintains the service models as the data changes over time. 

    In terms of capability and suitability, there are some services for which either approach works well. For other situations, one or the other is preferable. The user experiences of the two approaches are different.

    Can I leverage the model created in Discovery SAAM in my AIOps service blueprint? 

    No. At present, it is not possible. 

    Can I leverage the model created in AIOps service blueprint in Discovery SAAM? 

    Yes. You can add a business or technical service to another SAAM model, regardless of how it was defined.

    • Blueprints make it easy to express a simple rule that identifies all the elements of your service. Generally, this advantage applies to most of the technical services. 
    • Because the graph traversals are completely described in a blueprint, it is easy to understand the reason for including or excluding a particular node in a service. 
    • You define a rule once and use it many times. If you have many services with the same basic graph structure, you need only to define the rules once and apply them to as many services as needed.
    • If you need shapes that are not uniform or too complex to create as graph structures, take advantage of the CI attribute to create selectors as part of your blueprint.
    • You do not need to know any idea about the graphical structure or shape of a service before you create it. For example, a complex multi-tier enterprise software has many diverse shapes, and often different instances (production, development test, and so on) are different shapes from each other. SAAM automatically handles those differences with no effort from the user. 
    • Services often change shape over time, for example, adding extra layers of load balancing or clustering existing standalone databases. SAAM automatically adapts to these changes, but a blueprint would require updates from the user.
    • SAAM has a clearly defined workflow for developing, validating, publishing, and revising models that is important for some customers.
    • Blueprints are good at handling rule-based services, such as technical services (for example, London Oracle Database Servers). SAAM largely works by following relationships between nodes, so it is not as good of a match for these types of services. 
    • Because Kubernetes has a fixed hierarchical structure (namespaces, deployments, pods, and so on), both blueprints and SAAM work well for services primarily deployed that way. 
    • In real-world customer usage, CAM shows that often rules-based models require hard coding with the many details of a service, which makes the changes are difficult to implement. The blueprint-based models have the same characteristics as CAM, so the results are the same. However, SAAM models automatically adapt and tend to tolerate changes in the data better. 
    • Complex multitier services are usually much easier to model by using SAAM.
    • Some heavily connected technologies are currently not well understood by SAAM, and the users must teach it to remove many unwanted nodes. In such situations, a blueprint-based model works better.
  3. Knowing what business services are supported by which part of the IT infrastructure is essential to effective Business Service Management (BSM). Typically, most organizations have a list of the most critical applications, most of them tied to Service Level Agreements (SLAs). The goal of Collaborative Application Mapping (CAM) is to find out what hardware and software support which business applications, and to build the applications into service maps that can automatically be maintained. This is true for both enterprise and mainframe environments. A dynamic, automatically maintained, effective application map enables you to understand the key relationships between how your business operates and the infrastructure that supports it. It also becomes the initial, crucial part of Service Impact Analysis by maintaining accurate service models for BSM. 

    The CAM approach is designed to capture the rules that define where an application is running, not to simply define that information statically. This means that as you deploy the applications more widely in your estate, or you migrate them around your infrastructure, your service maps will stay current.

    For more information,  Introduction to Collaborative Application Mapping. Open link

  4. No. Not yet.

    The BMC Helix AIOps service blueprint and BMC Helix Discovery CAM are similar and have overlapping capabilities. At present, there are some features in CAM that are missing from blueprints, and there are features that are unique to blueprints.

    Advantages of blueprintsDisadvantages of CAMs
    • Blueprints contain parameters so users can create multiple instances with different parameter values.
    • Blueprints can contain any Discovery inferred node kind and any relationship kinds between them.
    • The BMC Helix AIOps UI for service blueprint is modern and sleek compared with the CAM UI.
    •  In CAM, each service definition has its own independent set of rules.
    • CAM has a very limited set of node kinds that can be included.
    • CAM supports a much wider range of operators for identifying and filtering nodes.
    • CAM can only create business applications.
    Advantages of CAMsDisadvantages of blueprints
    • A single CAM definition can contain rules to identify multiple instances of an application. In CAM, the user defines rules to identify and separate the instances. For example, identify and separate development and production instances or instances for different regions. The system then automatically creates multiple services and adds and deletes services as the data changes. 
    • CAM can use attribute data from matched nodes to search for other nodes even if they are not linked by relationships in the Discovery data. 
    • CAM collects nodes into named functional components, which are stored as related nodes in BMC Helix Discovery. Users can then view and report on these components. However, this feature is not yet available in SAAM.
    • With blueprints, the user must create each instance separately and provide the matching criteria for each one manually.
    • Blueprints can only find nodes by following relationships.
    • Blueprints can only create business services.

  5. That is the long-term intention, but we cannot do so until all the CAM features are available in a modern UI. Many existing customers have models that use the CAM features. The BMC Helix Discovery service model back-end that is shared by BMC Helix AIOps blueprints and BMC Helix Discovery SAAM supports all of CAM’s features, so it would be possible to translate CAM models into equivalent rules-based models, but we still need to build a suitable UI for the user to edit them.

  6. No. You can only delete blueprints that are not associated with any services. However, you can remove the blueprint from the associated services and delete it.

  7. No. You can only delete blueprints from BMC Helix AIOps. However, you can unpublish a blueprint from BMC Helix Discovery.

Service health and impact

  1. Health score for a service is computed by using causal events that are associated with each of the service entities and the significance derived from the service topology. 

    By default, all events are considered for computing the health score of a service and the health score is propagated from the child services to a parent service. However, you can customize how the health score should be computed and whether the impact should be propagated by using the following configuration options:

    • Health indicators
    • Event rules
    • Balancing profiles
    • Health severity score and status
    • Health impact propagation

     For more information, see Understanding service health score

  2. You can customize the values of the health score and status by modifying the default values. For creating your own custom rules for health score calculations, see Customizing health score and health status

  3. Yes, monitor all the services on the Services page, click an impacted service and perform ML-based root cause isolation. For more information, see Performing ML-based root cause isolation of an impacted service.

  4. Multiple CIs can be associated to a single change request in BMC Helix IT Service Management. However, when the change events are generated in BMC Helix Operations Management, the number of events generated are equal to the number of CIs in this case. For example, if there are 10 devices associated with a single change request, there will be 10 change events generated, one each for a device. Hence, the change requests count in BMC Helix IT Service Management does not correspond to the number of change events listed in BMC Helix AIOps.

  5. No. If a blackout policy is running in BMC Helix Operations Management, events generated in the blackout period are not shown in BMC Helix AIOps and are not counted for an impacted service. 

    For more information about how events are handled in the blackout period, see Blackout policies. Open link

Service prediction and outage

  1. BMC Helix AIOps uses the health indicators defined as part of a service to predict the potential service outage. The health indicator data are collected for 8 hours duration. The collected data are then processed through the Kalman filter algorithm for a state-space ML model to show the first service outage prediction within the next 24 hours.

  2. In BMC Helix AIOps, insights are calculated based on GMT date and time.

  3. In BMC Helix AIOps, the minimum training period for the AI/ML algorithm for a real-time outage prediction is 8 hours. Even though you can start seeing the results immediately, better efficacy comes after the first eight hours. The algorithm analyzes the last seven days of data. Data retention and storage capacity in BMC Helix Operations Management. Open link

Events and Situations

    1. Contact BMC Sales Team to subscribe to use this feature. 
    2. Enable the AIOps Situations option from the Configuration > Manage Product Features page. For more information, see Enabling the AIOps features.
  1. Enable the Configuration > Manage Situations > Advanced options > Show policy-based Situations. For more information, see Configuring ML-based situations.

  2. Do one of the following steps: 

    • Go to the Configuration > Manage Situations > Advanced options and disable Show policy-based Situations option.
      For more information, see Configuring ML-based situations.
    • Go to the Configuration > Manage Situations and click Reset to Default.


    Use the Reset to Default option, only if you want to reset all the settings on the page to the default values. To hide only the policy-based Situations, disable the Show policy-based Situations option.

  3. At least two events are required to create a situation.

  4. The service model and its topology, event, and event types are required to create ML-based situations. The change requests must be associated to a service existing in BMC Helix Discovery.

  5. Preprocessed event message and the event entity type such as CPU usage in VM, Response time in tomcat5, and so on are used to create the event signature.

  6. Based on the event message and its entity type, the algorithm decides the event slots that will be used to create the event signature.

  7. Event signatures are used to uniquely identify similar events and create a preliminary group. These event signatures further leverage service topology, temporal, and knowledge graph dimensions to assign events to respective situations.

  8. Only stable or saturated ML-based situations are considered for correlating as primary or similar situations.

  9. Only those change requests meeting the following criteria are considered to be displayed along with the situation:

    • You must have subscribed to the change management in BMC Helix IT Service Management.
    • The CIs associated with a change request in BMC Helix IT Service Management must be part a service existing in BMC Helix Discovery
    • The changes must contain one of the following stages. All other stages are ignored
      • Implementation In Progress
      • Completed
      • Closed
    • The changes must have been defined with one of the following impact levels. All other impact levels are ignored
  10. In BMC Helix Operations Management console, use the dynamic enrichment policy to enrich multiple host names based on the event location. For example, enrich the host name in the event to Houston.domain.com if the event comes from the Houston location and enrich the host name to Dallas.domain.com if the event comes from the Dallas location. For more information, see  Example: Enrich the source host name by parsing the event message. Open link

  11. Yes. A situation is closed automatically if the following conditions are met:

    • Approximately 5-10 minutes after the situation is stable or saturated. A situation is stable when no new events are aggregated. The default stability window is 30 minutes.
    • All events that are a part of the situation are closed and no new events are correlated as the event correlation time window (default 15 minutes) has passed.

Time zone preferences

BMC Helix AIOps uses the user's browser time zone as the preferred time zone. Additional options to set time zone is not available.


  1. BMC Helix AIOps uses BMC Helix Intelligent Integrations connectors to get data from third-party vendors. For more information, see Sources supported by BMC Helix Intelligent Integrations. Open link

    • Check if you have the required permissions to view data in BMC Helix AIOps. For more information, see Roles and permissions.
    • Check if you have subscribed to at least one of the data providers that work with BMC Helix AIOps. You will see data only if you have subscribed to one or more data providers.
    • If you are a new customer, contact  BMC Sales Team Open link for assistance.
Was this page helpful? Yes No Submitting... Thank you