Impact 2024: The Industrial Data and AI Conference for and by Users | Nominate Speakers Now for a Ch...
Hi @Marcela Young - thanks for your feedback! These are the Templates we discussed relevant for maintenance execution, correct? As discussed, we could defiantly create these Templates today, but we’ll need to do some discovery on how to make surface them in the context of e.g. an equipment or a Work Order that you are executing. But defiantly interesting for InField (cc @Nicklas Lind). Will update you for more insights when we start doing discovery on this. Br,Kristoffer
Hi @rsiddha - thanks for the feedback :) How I read your feedback is that you need “versioning” on the Templates, is that correct? Should you can always choose to use revert back to an older version of the Template if needed? “Versioning” of Templates is something we’ve been discussing in the team as a valuable feature. Currently we haven’t done too much exploration on it, but we have it on the backlog to do it. Thanks!
Hi @Marcela Young and @rsiddha - thanks for providing this feedback. This is actually something we’ve seen the need for before, and if I understand you correctly this is similar to the feature request here? We are planning to have support for this in the Templates creator, most likely during Q2. (cc @Nicklas Lind ) Br,Kristoffer
Hi @Marcela Young - thanks for the feedback on behalf of Raj. I believe I understand the use case with linking the entire Template to a specific asset rather than each Template Item. We’ll see how this can be solved, but would be very interesting to sit down with Raj in the future to fully understand these type of use cases from a Reliability perspective. Regarding reading QR codes to bring up asset information, this is something InField supports today. Are you referring to a different kind of QR code use case?
Hi @EViswanathan - thanks for joining in. Ideally, we want to be flexible on what SAP data objects that are presented in InField. Meaning that the customer should be able to configure what SAP data objects that are presented in InField based on what has value for the technician out in the field. Of course the requirement will be that these data objects are liberated and modelled in Cognite Data Fusion. Not entirely sure what you mean by “do we have any defined process that what kind of data to be maintained against equipment”, so please elaborate. Cognite Data Fusion handles the link between SAP data objects (e.g. work orders) and equipment data (asset hierarchy, documents, sensor data, etc.). MoC happens in the source system, while our extractor pipelines ensures that any changes are reflected in Cognite Data Fusion.
Yes, write-back scenario is also very relevant. From InFields POV, there are two main write-back scenarios to the CMMS we want to have support for. For SAP these are Notifications and Work Orders. As you know, we are looking into Notifications as the first write-back scenario, capturing observations from the field. The case you describe above will be relevant for the second one, the work orders, so let’s have a proper investigation of which fields that are relevant to write-back to (e.g. status, hours, etc.) when we get to that stage. Thanks!
Hi @rsiddha & @Benjamin A Onweni - thanks for the feedback. Having an improved process around creating/editing Templates before pushing the changes to production (ready to be executed on) I very much agree with. We are trying to mitigate some of these challenges now, e.g. what you mention on synthetic tags. I don’t think we’ll solve this with separate environments, but rather with something like a “template lifecycle status”, e.g. draft → production. Will update you when we have more on this. Yes, agree that we can merge these two - @Anita Hæhre, could you do that?
Hi @ibrahim.alsyed - thanks for the feedback. From InFields point of view, our ambition is to give the maintenance technicians out in the field the data they need to do their job effectively. Data from the CMMS, e.g. SAP, is of course relevant for this, totally agree with you. Today, you have access to SAP work orders, Notifications and Operations through InField, but our plan is to have flexibility to showcase more SAP data types that are relevant for the technicians. Based on our current timeline, this is probably something for later H1, but would be very valuable to sit down with your maintenance technicians to understand what type of SAP data they would need and how they would use it to do their job effectively.
Hi @hescalona - thanks a lot for this feedback. I totally agree with you, we should provide a much clearer message to the user if this is the case. Br,Kristoffer
Thanks @asgottlieb & @ibrahim.alsyed ! Great that you enjoy the equipment → parent feature. When it comes to accessing children (and it’s relevant data) I agree that it’s a need that makes a lot of sense. The problem is the potential amount of data and how this is presented in a nice and intuitive way (especially on mobile), such that it’s actually valuable and not just “noise”. There’s probably cases where even “grand-children” data is relevant as well, which will mean an even larger amount of data. Will gather your comments above and reach out to you when we start detailing this out internally. Thanks!
Hi @ibrahim.alsyed ! First part of this feature was part of the previous release, please see an update here: When it comes to scheduling when a Checklist or Sections should be “N/A” based on e.g. planned outages, this is something will look into at a later stage.
Hi @DGrooms - as @davidhwu mentioned above, we are happy to say that this functionality was released today (see the release notes here; https://docs.cognite.com/infield/changelog/). You now have the possibility to either mark the remaining tasks in the whole Checklist or a Section with the same state (ok, not ok, Not applicable, etc.). Remember that to put either one item or multiple items as “Not applicable” you need to have this state applied in the setting page for the particular Template (see the image below). If you don’t have access to editing Templates, reach out to one of your admins. We hope this makes things easier for you and please reach out with any comments/feedback!
Hi @asgottlieb - following up on this one. After this input we have released a way of navigating the asset hierarchy through the “search field”, the reason for not implementing a full hierarchy was to not ruin the mobile experience. Have you tested the “search” experience and does it meet some of your needs for a hierarchy?
Hi @ibrahim.alsyed! I believe the plan that was sent over by Marius prior to Christmas still stand, that we want to have write-back of Notifications to SAP triggered from InField during H1. In accordance to that plan a Celanese specific execution plan will be ready during February.
Yes, that could make sense 👍 Currently the logic is built around the concept that each real-life facility/platform is modelled as the root asset, and then we search all assets beneath that root. This logic made sense in O&G, as each platform is “decoupled” from the rest (easy to say platform A = root A), but probably something we need to re-evaluate now that we see several units (roots) within one facility that have dependencies on each other.
Hi @crgomez13 - thanks for the feedback. This is something we’ve seen the need for across users, especially when working with (as you point out) large templates. Will bring it back to the team.
Hi @crgomez13 - thanks for the feedback. We agree, this is something we’ve observed both at Celanese and other customers. We are planning to incorporate functionality for this in a future release (cc @Nicklas Lind).
Hi @crgomez13 - thanks for the feedback. Today, this logic is controlled by how the asset hierarchy is modelled in Cognite Data Fusion, e.g. every asset below the root node “AAS” can be “linked”. I agree that it makes sense to de-couple this logic, such that you are able to maintain an asset that is not aligned with the unit. We’ll see what we can do here.
Hi @crgomez13 - thanks for the feedback. We’ve seen the similar need for these “if statements” before, and are thinking around a concept for it. Do you know which Unit that at Clear Lake that has brought this up? Thanks! (cc @Nicklas Lind)
Hi @crgomez13 - thanks for forwarding this feedback. The need to ensure standardisation, e.g on units, makes a lot of sense.
Hi @rsiddha - thanks for reaching out. For Cognite InField this is currently not possible. I’m certain that it exists scenarios where it would make sense for InField to trigger an email, but unsure if this is one of those scenarios. But happy to discuss this more. For CDF in general we have multiple places where sending emails are triggered as part of a workflow, e.g. on extractors and AIR. However, I do not believe the scenario you are describing here is currently possible out-of-the-box.
Thanks @rsiddha - will bring this feedback into our “internet connection” discovery work.
@rsiddha - this is on our list and the ambition is to have a solution for it within that timeline. Thanks!
Hi @Crystal Connor Richards ! Cognite InField would work fine on a screen of that size. However, InField determines if the device is a Desktop or Handheld device based on the device width in pixels. If InField determines that it is a Desktop device, touch features won’t work, so you would have to demo it using a mouse and keyboard. Do we know what the resolution of the device is? That would have an impact on the device width in pixels and therefore if InField would categorise it as a desktop or handheld device 😀
Hi @rsiddha - thanks for your feedback. This makes a lot of sense, will bring it back to the team. Thanks!
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.