Skip to main content

Assets

This section outlines the process of creating and configuring assets, their allowed modes of operations and states they can be in. Assets are managed via the Asset Tree Editor screen. Users with the appropriate roles can define the hierarchy, type, group, and other parameters.

Asset Hierarchy​

An asset is any entity that needs tracking or summarizing within the operational environment. Assets represent different physical or logical elements within a manufacturing setup and may refer to a specific machine, a manufacturing line, or an entire factory. Assets are organized in a hierarchical structure.

assets

ISA-95 Equipment Hierarchy​

ISA-95 defines a strict hierarchy for your plant equipment consisting of Enterprise > Site > Area > Line > Cell or Cell Group. You can create an ISA-95 compliant equipment hierarchy, but we don't force you to follow that model if it doesn't fit your needs. Our model allows you to create a multi-enterprise asset tree and organize your assets by region or division or department or however you want to. At a minimum, we still need sites somewhere in the hierarchy to associate timezone information to assets. After that it's up to you.

Asset Configuration​

assets

Add or Edit an Asset​

You can add an asset anywhere in the asset hierarchy by selecting a row in the asset table and clicking the 'Add' button. To edit an existing asset, click on the edit button after selecting the asset.

assets

  • Asset Name: The name of the asset. Asset names must be unique within the parent.

  • Asset Types: Used for defining the type of an assets, akin to the ISA 95 hierarchy (e.g. enterprise, site, region). To configure asset types, use the edit button next to the 'Filter by type' dropdown at the top of the page.

  • Asset Groups: An asset can be associated a group such as 'shredders'. Grouping allows for analysis of assets that may not be in the same hierarchical area but need to be reported similarly. For instance, Assets like 'box formers' across different lines can be grouped under a single Asset group for consolidated reporting. To add an asset to a group, simply select the group from the dropdown. If the group doesn't exist, start typing the name of the group into the dropdown and select 'create'.

  • Sort Order: Determines the asset's position relative to others.

  • OEE Type: One of the primary uses of an asset in Kanoa Ops is enabling it for OEE tracking. An OEE_Enabled Asset refers to any physical piece of equipment such as a production line, vessel reactor or process cell where operational data such as counts and equipment can be obtained and needs to be monitored. If an asset is set to OEE_Enabled, targets can be set for performance, availability, quality, and overall threshold that are used in visual indicators while an asset is in production. An instance of our assetOEE tag UDT is also created in the [Kanoa] tag provider that provides a mechanism for connecting te physical machine to our MES. See the [Configuring Tags] section below.

  • Custom Attributes: Meta data about an asset can be stored against an asset in the custom attribute tabs. We use '_tz' to store timezone information about a site, but you may want to store information such as the ERP name for asset or the path to a custom setup screen for a specific asset. whatever the use case, you can create whatever you want by typing in the name of the attribute and selecting 'create'. Once an attribute has been created, it will become available for any asset of the same type.

Duplicate Asset assets

Select an asset from the hierarchy and click the 'Duplicate' button to make a copy of the asset. The entire configuration for the asset is duplicated including child assets, custom attributes, mode, state and item links.

Delete Asset assets

Remove assets from your hierarchy. If there are child assets or event history associated with any part of the asset hierarchy, the user will be warned that 'deleting this asset will also remove historical data'. This action cannot be undone.

Import/Export Asset assets

An asset hierarchy can be exported and imported to another gateway using the import/export buttons. This utility works the same as the 'Duplicate Asset' in that the entire configuration for the asset will be exported.

Asset Modes​

A mode defines the intended operation of an asset. The mode is typically set by the schedule or manually set by the operator, but can also be set via a mode tag when the asset is configured as 'OEE_Enabled'. Modes are used for scheduling assets using the Operations Scheduler in Kanoa Ops. This tool allows for the planned assignment of modes to various assets, ensuring that each piece of equipment is in the correct mode for its intended operation at any given time. In addition to being scheduled, Modes can also be manually controlled via the Line Operation screen. This feature enables operators or supervisors to dynamically adjust the mode of an asset based on real-time operational needs or changes in the production environment.

To modify modes and link them to an asset, click on an OEE Enabled asset and select the 'Mode tab'.

Mode Configuration

Modes​

There are reserved modes predefined by the system such as 'Unknown', 'Idle', 'Production', 'Changeover', 'Maintenance'.

  • Unknown: Serves as a catch-all state for uncertain scenarios or unclassified states of the asset.
  • Production: The primary mode where assets are actively producing products. This mode indicates readiness for production and active engagement in the manufacturing process.
  • Idle: The default state for an asset when it is not actively working but is available to produce. It represents a standby or waiting condition.
  • Changeover: Used during the transition between different production runs. It covers setup activities, cleaning, and other preparatory tasks needed to switch products or start production.
  • Production Delay: Used purely by analysis to determine how much time an asset has been delayed when scheduled to be in production. It is determined by the asset being set to a production mode, but no workorder or product has been selected.

New modes can also be created and associated with an asset. This is where you can customize the application to suit your manufacturing process. The mode indicates the production context of an asset and is an important aspect of how utilization and production performance analytics are determined.

Mode Types​

Mode types are used to categorize modes. Mode types cannot be modified and are pre-defined by the system. The important mode type is 'Production' as only asset count and state events that occur during modes of type 'production' are included in production anaylsis. Mode types however are used along with modes to provide insight into asset utilization, in terms of 'how much time do my assets spend idle available for additional capacity compared to changeover, or setup, or CIP or maintenance.

Mode Types consist of....

  • Cleaning
  • Idle
  • Maintenance
  • Other
  • Production
  • Setup

Configuring Modes​

Adding & Editing Modes​

Mode Configuration

  • Name: Name of the mode. Mode names must be unique.
  • Type: Select the mode type for this new mode.
  • Enabled: Indicates if the mode is active and usable within the system.
  • Can Select: Determines if an operator can set an asset to this mode from the asset operation screen.
  • Can Schedule: Determines if an asset can be scheduled to be in this mode.

Linking Modes to Assets​

Once created, modes are linked to assets. Each mode is assigned a unique mode code. While the value used for a mode code is not important, it must be unique for the asset modes. If the mode for an asset is to be set via a plc tag, then the mode code defined should match between the PLC and MES.

  1. Select asset or assets from the asset tree.
  2. A list of modes assigned to the selected assets will appear in the bottom pane showing the mode link id and mode code.
  3. To link a mode to an asset, select one or more modes and click the 'Link' button. The mode will appear in the bottom pane.
  4. Assign a numeric mode code for the asset mode.

Auto-Schedule
By default, a mode will have the 'auto-schedule' bit set, which allows the scheduler to set the asset to this mode when scheduled and the asset is currently in an 'idle mode. To clear the auto-schedule bit, simply double-click in the 'Auto Schedule' column and set to false.

Unlinking Modes from Assets​

Modes can be unlinked from assets using the unlink option available on the screen. If event history exists for a mode, the system will not allow you to remove the link. It will instead be disabled.

Asset States​

While Modes represent what an asset is supposed to be doing, states show what the asset says it was actually doing. States are crucial for accurately understanding the availability component of OEE (Overall Equipment Effectiveness). They provide insights into:

  • Actual running times
  • Instances and reasons for unplanned downtime
  • Categorization of downtime for analysis and improvement

States help in capturing and reporting the true operational status of assets, playing a vital role in efficiency analysis and operational optimization.

State Management

There are certain reserved states predefined by the system such as 'Running', 'Off-line', 'Idle', 'Faulted' that cannot be removed from the system.

Offline: Typically used with a state code value of 0 to indicate that the asset is powered off or disconnected.
Running: Indicates that the asset is operating as expected.
Idle: Indicate asset is not currently running and no faults exist.
Faulted: Indicates a fault or error, suggesting a breakdown or malfunction.

New states can be created and will generally align with the machine states or fault codes expected from the asset.

Adding, Editing & linking States​

Click the State Management to add a new state or select a state and click State Management to edit an existing state.

State Management

State Name is the name of state. State name must be unique State Types are used to categorize the state. State types are pre-defined by the system and should not be modified. State Types consist of... Running, Planned Downtime and Unplanned Downtime. State Categories are used solely for analysis. You can define any category via the drop down by typing in the name of a new category and selecting 'create'. Examples of categories may be 'quality', 'electrical', 'mechanical' where you would want to analyze your downtime to see how much was related to say quality issues. Asset Group allows you to classify certain states as say being specific to a drill press, reactor or filler. It is optional and can be left blank.

Linking State to Assets​

States can be linked to an asset using the State Management. Each state is assigned a unique state code. The state code should match what will be set by the asset via the plc tag. click in the table in the PLC code column to edit the state code assigned to this state.

States can be unlinked from assets using the unlink option available on the screen. If event history exists for a state, the system will disable the link and not remove it.

Configuring Tags​

Whenever an asset has its 'OEE Type' set to 'OEE_Enabled', an instance of our assetOEE tag UDT is created in the [Kanoa] tag provider.

The Inputs folder is where we connect the asset to its source of data. At a minimum, we'll want to connect to counts (infeed ,outfeed, waste) and to the state of the machine i.e. running or faulted. If we don't have all the counts, then no problem, we only need one count. But in order to determine OEE Quality, we will need two counts and we will automatically calculate the missing count.

If operations are started through the MES Application (Operator screen) or started by the schedule, that is all we really have to connect, however if the asset is operated from a different HMI or SCADA, then we can simply connect the Mode, Work Order and Product Code tags to the source, to fully capture production information within our MES.

assetOEE

Part Required, Machine ID and Tooling were all client custom requests at some stage.

Inputs/Machine ID This tag allows you to set which cell on an asset caused the downtime event. So if you have an asset 'Packaging Line 1' with cells 'Filler', 'Capper' and 'Palletizer', you can set the Machine ID to the assetId for the Filler cell (7) and set the State to the stateCode linking the Filler to 'CIP i.e. 127

Inputs/Tooling This tag that can be used to track the serial number or part number for a jig or mold used by an asset. That in turn can be used to track the number of counts against a tool, which can in turn be used to notify when a tool needs to be replaced or sent for maintenance. We can also use it to trigger quality checks whenever the tooling is changed, and finally it can be used to track which tool was used to produce which lot of material.

Inputs/Part Required This is currently only used in the Reliability KPIs analytics screen. That analysis screen breaks production hits into 'Loss Buckets', one of them being 'Breakdown' which was determined by a part needing to be replaced.

Inputs/State Inside the State tag change script is the stateChange() function. It is here so it can be customized for the client and even be different for each asset.

If you look at this function, its behavior is set as follows...

  • If the state changes to 'Running' state type, we add a new stateEvent.
  • If the state changes to 'Unplanned' or 'Planned' Downtime state type from a running state type, we add a new stateEvent.
  • If the state changes to 'Unplanned' or 'Planned' Downtime state type but was already in a downtime state type, we update the current stateEvent. In this case we are presuming the operator has coded the downtime reason before starting the machine back up

The only thing that is done here with the 'Part Required' tag is store it as meta data along with the state event. We use the function system.kanoa.event.updateStateEventInfo(stateEventId, 'partReqd', stateInfo['partReqd'], userId) to store any kind of extra data we care about. It is currently only used in the Reliability KPI's screen, but you can probably tell, it means we can customize the implementation however we want around storing state events.


    def stateChange(stateInfo, userId):
    
        '''
        This function can be overridden to customize it based on a clients needs.
        
        The example implementation here was specific for a client. 
        Change state logic so that a new downtime code entered when state is already down will over-write current state rather than adding a new state change.
        Client has their operator code downtime events before they allow the line to start up. 
        If the current state is 'unplanned downtime', then update the current state record when it changes to a different state that is not 'Running' (or 'Idle'?)  
    
        Example stateInfo dictionary
        stateInfo = {'assetId': assetId, 'assetStateId': assetId, 'stateCode': stateCode, 'partReqd': tagValues[2].value, 'tStamp': currentValue.timestamp, 'assetPath': tagValues[3].value}    
        
        Updated:
            jfc: 1/27/24 Missing origStatecode param in updateStateEvent() call
        '''
    
        dbName = system.kanoa.config.getDBName('MES')
        mesTagProvider = system.kanoa.config.getTagProvider('MES')
        log = system.util.getLogger('kanoaTags')
    
        debug = system.tag.read(mesTagProvider + 'kanoa/debug/tags/debugFlag').value
        if debug: log.info('stateChange() called with %s'%stateInfo)
        
        stateEventId = None 
        if stateInfo['assetId'] is None or stateInfo['assetStateId'] is None or stateInfo['stateCode'] is None: return None #log.error("Invalid parameters passed to stateChange() - %s"%stateInfo)
        
        stateInfo['stateType'] = system.kanoa.utilities.getFieldValue('stateTypeName', system.kanoa.asset.getAssetStates({'assetId': stateInfo['assetStateId'], 'stateCode': stateInfo['stateCode']}))
        if stateInfo['stateType'] is None: log.warn("No state information configured for this stateCode - %s"%stateInfo)
            
        prevStateEventInfo = system.kanoa.utilities.convertDatasetRowToJSON(system.kanoa.event.getPreviousStateEvent(stateInfo['assetId'], stateInfo['tStamp']),0)
        if prevStateEventInfo['stateEventId']: #We have an entry prior to this timestamp
        
            if stateInfo['stateCode'] == prevStateEventInfo['stateCode'] and stateInfo['assetStateId'] == prevStateEventInfo['assetStateId']: return #  log.warn("State and assetId is the same as the last entry. Doing nothing")
            elif stateInfo['stateType'] == 'Running': 
                if debug: log.info('New state type is running.  Calling addState()')
                stateEventId = system.kanoa.event.addStateEvent(stateInfo, userId)
            elif prevStateEventInfo['stateTypeName'] == 'Running' and stateInfo['stateType'] != prevStateEventInfo['stateTypeName']: 
                if debug: log.info('Last state type is running.  Calling addState()')           
                stateEventId = system.kanoa.event.addStateEvent(stateInfo, userId)
            else: #If we are here, then old and new state must be downtime. #In this case we will update the last downtime event to what has just been passed in. This is the operator coding the downtime event before starting the line back up
                if debug: log.info('Previous state and current state are both downtime. Updating State')
                if system.date.minutesBetween(prevStateEventInfo['tStamp'], stateInfo['tStamp']) > 300: stateEventId = system.kanoa.event.addStateEvent(stateInfo, userId) #More than five hours, should we just add a new downtime state?
                else: 
                    stateInfo['stateEventId'] = prevStateEventInfo['stateEventId']
                    stateInfo['origAssetId'] = prevStateEventInfo['assetStateId']
                    stateInfo['origStateCode'] = prevStateEventInfo['stateCode']
                    system.kanoa.event.updateStateEvent(stateInfo, None)
                    stateEventId = prevStateEventInfo['stateEventId']
        else: stateEventId = system.kanoa.event.addStateEvent(stateInfo, userId) #if debug: log.info('No data found for last state')
    
        if stateInfo['partReqd'] and stateInfo['stateType'] != 'Running': system.kanoa.event.updateStateEventInfo(stateEventId, 'partReqd', stateInfo['partReqd'], userId)
        
        return stateEventId

    if currentValue.value != previousValue.value and currentValue.value is not None:
        #State interface is entirely customizable. You can pass whatever values you want to the system.kanoa.asset.custom.stateChange() function
        #which can be overridden in the runable project to add any cunstomization required
        tagValues = system.tag.readBlocking(["[.]../EquipID", "[.]Machine ID", "[.]Part Required", "[.]../eqPath"])
        assetId = tagValues[0].value
        machineId = tagValues[1].value
        assetStateId = machineId or assetId #The stateCode can come from a cell of the asset that has its own states defined. This tells us the lookup for the stateCode
        userId = system.tag.read("[.]../Configuration/userId").value
        
        if currentValue.quality.isGood(): stateCode = currentValue.value 
        else: stateCode = system.kanoa.utilities.getFieldValue('stateCode', system.kanoa.asset.getAssetStates({'assetId': assetId, 'stateName': 'Off Line'}))
        
        stateChange({'assetId': assetId, 'assetStateId': assetStateId, 'stateCode': stateCode, 'partReqd': tagValues[2].value, 'tStamp': currentValue.timestamp, 'note':None, 'assetPath': tagValues[3].value}, userId)

    return