4 Replies Latest reply on Jun 5, 2017 4:27 PM by Hahnming Lee

    Rollup Calculation  Attribute Timestamp

    Srinivas

      Hi,

       

      We are using AF Server 2016 R2 and have noticed that Rollup calculation attribute timestamp always showing timestamp "01/01/1970 12:00:00" which defalt timestamp for attribute in AF. It doesn't honor the trigger time which is scheduled for 10 minutes.

      Rollup calculation results not being written to tags.

       

      Has anyone noticed this issue? some  ideas how to resolve this are appreciated.

       

       

       

       

      Regards

      Srinivas

        • Re: Rollup Calculation  Attribute Timestamp
          Roger Palmen

          The rollup takes the timestamp from the input attributes. If these are not PI Point, these likely cause the date you are seeing.

           

          Can you show a bit more about your data & configuration to help you pinpoint the problem?

          • Re: Rollup Calculation  Attribute Timestamp
            Hahnming Lee

            This would make it seem like the person configuring this actively changed the configuration from using a PI point data reference to using no data reference. This behavior usually requires first creating the rollup and then changing the configuration later. We added checks in 2.7.0 to discourage users from doing this. It is not recommended. Since the attribute is printing out the timestamp of the data reference, it will continue to show no timestamp as long as it is a "None" data reference. The recommendation is to write the data to a PI point.

            1 of 1 people found this helpful
              • Re: Rollup Calculation  Attribute Timestamp
                Srinivas

                Hi Lee/Roger,

                 

                Sorry for the late response. All the attributes configured in the rollup calculation  are Table Lookup DR (3rd part data source) not the PI Point data reference.  Also, DR have not changed from the beginning of the configuration.

                Here is the illustration of the hierarchy.

                - Group1

                     -- Group 2  -Configured RollupSum at level on attribute "Attr1" at periodic interval of 10 minutes or less and expecting that it would honor the timestamp of "Attr1".The result is not  being written to tag

                                Attr1Sum - Group3 Sum

                          ----- Group 3 -- Configured RollupSum at this level on attribute "Attr1" at periodic interval of 5 minutes and expecting that it would honor the timestamp of "Attr1". The result is not  being written to tag

                                         Attr1Sum - The result is not  being written to tag -- Sum of all Elements under Group1

                                         + Element 1

                                                   Attr1 - TableDR - Show corrects time stamp from 3rd party data source (Oracle database).

                                         + Element 2

                                         + Element 3

                3rd part data source is single source of truth and don't want to have source data in multiple places. hence, all calculation are being configured as dynamic at this moment in AF to make them available in PI Coresight

                 

                Regards

                Srinivas

                  • Re: Rollup Calculation  Attribute Timestamp
                    Hahnming Lee

                    Right, it's fine that you're aggregating non PI Point DRs in your rollup, but the result is always going to read off the timestamp of the DR which it is writing to. In this case, that is no DR, which will always result in a client timestamp of January 1, 1970. So while the hierarchy looks correct, and I have no doubt that Oracle has the correct timestamp and that the Table Lookup DR is correctly configured to give the correct value/timestamp combination, if the rollup (Attr1Sum) does not output to a tag, you will only be able to get the right value, at best. Even then, there's no troubleshooting mechanism to figure out if the value is correct because there's no timestamp to correspond it to.


                    It sounds like you are writing to all (or many) non PI Point DRs with analyses. I would strongly caution against that. This is not a recommended configuration and could result in performance issues as you attempt to scale up. Also, I would caution against thinking that this is "dynamic". It's much closer to "static" as it has no time context to it.