Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 13 22:22
    mpostol closed #634
  • Nov 13 22:22

    mpostol on master

    Release new version - synchroni… (compare)

  • Nov 13 22:21
    mpostol reopened #634
  • Nov 13 22:16
    mpostol closed #634
  • Nov 13 22:16
    mpostol edited #634
  • Nov 13 22:16
    mpostol edited #634
  • Nov 13 22:16
    mpostol edited #634
  • Nov 13 22:15
    mpostol edited #634
  • Nov 13 22:15
    mpostol edited #634
  • Nov 13 22:15

    mpostol on 6.4.8-Juliet

    (compare)

  • Nov 13 22:14
    mpostol edited #634
  • Nov 13 22:12
    mpostol edited #634
  • Nov 13 22:12
    mpostol edited #634
  • Nov 13 22:12
    mpostol edited #634
  • Nov 13 22:12
    mpostol edited #634
  • Nov 13 22:12
    mpostol edited #634
  • Nov 13 22:12
    mpostol edited #634
  • Nov 13 22:12
    mpostol edited #634
  • Nov 13 22:12
    mpostol edited #634
  • Nov 13 21:47
    mpostol milestoned #634
Mariusz
@mpostol
@Drutol I have added the issue that should solve the problem with custom implementation of the IEncodingFactory
EncodingFactoryBinarySimple has useless test of the repositoryGroup parameter. #304
This fix should be committed today and will be available on 400.
The Simulator development is really time consuming job, so the milestone is now overdue. There are two tricky point: making the simulator work and configuration generation. Hopefully I will PR to master a prototype at the beginning of the next week. So keep going focusing on your stuff.
Mariusz
@mpostol

@Drutol I am glad to say that the work on the factory (boilers set) simulator (alfa) is close to release. :simple_smile:

The starting point for boiler description is on the commsvr.com page:

boiler

Investigate also the document: section Custom model boiler

I will use this documents to prepare the simulator description, so you may read them in advance.

You may find also helpful downloading the
OPC UA Address Space Model Designer

It has the model attached as the embedded example.
The simulator documentation is planned as the #306 in the current milestone.

Piotr Szymczak
@Drutol
Roger. Thanks for update! As for me I've implemented obtaining GPS coordinates and I'm waiting for simulator now :)
Mariusz
@mpostol

@Drutol My concern is how to provide the observed device coordinates. We must consider two scenarios:

  1. Localization is fixed, e.g. boiler - the coordinates may be provided in the HMI configuration file.
  2. It is a moving device, e.g. train - the current coordinates must be transmitted over the wire.

In 2 the coordinates must be modeled and encoded - importance level is as the timestamp. I must ask my OPC UA fellows if we have any standard representation of the GPS coordinates.
Are you aware of that? The first approach is 1. but we should be ready to accommodate 2.

Piotr Szymczak
@Drutol
Hmm, I don't see an issue with different nature of coordinates sources on my side. And yeah, I'm implementing it having the "ball" example in my mind.
Mariusz
@mpostol
@Drutol hope you are right. Anyway the simulator exposing set of 4 boilers is on the master track. To switch on the simulator the RefereneApplication configuration must be modified. Diff it with App.BilersSet.xml. The simulator is loosely coupled with the ReferenceApplication. Hard references have been added to copy all assemblies during the build.
Your next step is to prepare the configuration for the Consumer - it must be mirror of the producer configuration. Test it with the DataLogger before integration with your stuff. It should log all data cumming from the simulator.
My next task is to prepare a documentation, but because I have a few other challenging project ahead I must slow down. Keep me informed about the progress.
Let me know how it works for you.
Piotr Szymczak
@Drutol
Okay, thanks! I'll try to get something done today.
Piotr Szymczak
@Drutol
image.png
Okay after some digging I got it running. Are the values supposed to change? Or are they constantly "0" right now?
Mariusz
@mpostol

@Drutol Good news. I haven't really tested the behavior of the boiler simulator . I have stolen it form the OPC Foundation stuff as is, but now my concern is where set points are provided. Anyway, the simulator is implemented in tempuri.org.UA.Examples.BoilerType.BoilerState:

    /// <summary>
    /// Updates the values for the simulation. 
    /// </summary>
    private void DoSimulation(object state)
    {
           //....
    }

Note it is partial and located in at : Networking\Simulator.Boiler\Model\BoilerState.cs

It seems that it was not implemented with real physic rules in mind, but it shout generate random data.

  1. First priority task is to prove that the communication doesn't generate any warnings in the log files (consumer and producer). Note, there are two log files -it is not perfect solution but ...it is.
  2. Next is to provide data from selected boiled on scree in real-time
  3. Improve simulator to behave as expected - our goal is not to simulate real boiler, but not all 0.0.
  4. Build a sophisticated mechanism to select one of the boilers in set using for visualization for example using observer (smartphone) geographical location.

If the configuration works fine, add the file to the DataLogger and PR back to me. Use similar name as for the producer.
Goo luck and inform me about success.

Piotr Szymczak
@Drutol
Screenshot_2018-07-29-14-01-46-781_CrossHMI.Android.CrossHMI.Android.png
I've successfully convinced the simulator to start doing actual "simulation" and the data reaches my application just fine.
  1. As for warnings in log files... I don't see any.
Piotr Szymczak
@Drutol
Now I have to include position in this simulation, would you rather like to see it in repository name or as a data member or is it up to me? Any updates from OPCUA on coordinates representation?
Piotr Szymczak
@Drutol
I've opened PR with fixed simulation.
Mariusz
@mpostol
@Drutol great job. I have merged it and updated the 400 branch (I am working on 400 to make master more stable). I have noticed the problem with starting simulation.
Mariusz
@mpostol

Now how to deal with the geographical localization? As I sad we must consider two scenarios:

  1. It is static, so it is not provided by the data transferred over the wire - it is HMI feature, so you must deal with it. Using the repository name is not the perfect solution (but possible), because it makes consumer/producer configuration synchronization very difficult. The OOI stuff is prepared for a situation like this by expanding the configuration file. An example you have in UANetworkingConfigurationUnitTest. I believe your work will be proof of concept in this respect. In your part of the configuration, you may add an array containing <key, value> pairs, where the key is repository name and value is geographical localization.

  2. It is dynamic (running train, rolling ball) the geo position must be provided as a variable with the part of relationship with the object model. But now it is not the case. So let's fix the static solution, and after that, if we have time we will think about the UA model containing localization. BTW, I have forgotten to ask :-1: , sorry about that. Fortunately, having proof of concept for a static case we may inform about the success while asking about this particular detail :smile: .

Mariusz
@mpostol
@Drutol switch on the issues in you fork to make me possible to add comments not related to public discussion. Your repository is private, so any comments related to your code must be added there. Additionally it seems that you should prepare and publish GitHub Pages. They are visible even for private repositories, so I will be able to add ref to you stuff if you don't mind.
Piotr Szymczak
@Drutol
I've turned on the issues. I guess I'll now check out this configuration expansion you mentioned.
As for GitHub Pages... hmm I don't really feel like there's much to present there. Any specifics in mind? I've prepared the static website generator though so I'm pretty much ready to go.
Piotr Szymczak
@Drutol
As for code itself... well... it's changing quite dynamically as of now so It's not properly tested nor commented yet.
Piotr Szymczak
@Drutol
I've been trying to find this extension you have been talking about but to no avail. I see some wrappers but I don't see how they are expanding anything, I've found ExtensionDataObject but I don't believe that this is what I'm looking for either. Also even if I do expand the configuration file I won't be given any data from the library when creating bindings for example so I would have to intercept the configuration somewhere anyway. Isn't it more feasible to create some other configuration file or just derive from existing ConfiguarationData class and forward extra data to some other component?
Mariusz
@mpostol

@Drutol I have added issue to your repository related to GitHub Pages.

Read more about GitHub Pages Basics.

GitHub Pages sites are publicly available on the internet, even if their repositories are private.

Therefore, GitHub Pages can be referenced by a link and available to the public community.

The content should follow the gist:

https://gist.github.com/mpostol/2d3f982ac548a272233956046625b2d6

As the starting point use your RAEDME.md and the project description:

OOI Projects

It should be cover page of your project. I have generated it from the README.md. See OOI

Mariusz
@mpostol
@Drutol to prepare an advice I need a while. I must investigate if there is a description on how to expand the configuration. I believe there are two approaches possible: wrapping and inheriting, but I ma not sure for now.
Mariusz
@mpostol

@Drutol configuration management followup:

I have reported a new issue:

mpostol/OPC-UA-OOI#312

The API I mentioned previously is dedicated to using the library as a component of a configuration editor. For the communication, it is not applicable, and the API is hard-coded so it must be modified. Let's assume the custom configuration must be derived from the ConfigurationData. Tomorrow afternoon I will provide a fix for that.

Mariusz
@mpostol

@Drutol as I said previously the code is ready to read any custom configuration derived from ConfigurationData or wrapping the ConfigurationData. Because you must provide the following function (LoadConfig() ) used to load configuration (Inverse of Control) you can define any type as the type parameter of XmlDataContractSerializers.Load<TypeParameter> that meets the requirements. Additionally, you are not obliged to use XmlDataContractSerializers.Load<TypeParameter>, so, for example, you may load the configuration from resources if applicable.

    private ConfigurationData LoadConfig()
    {
      FileInfo _configurationFile = new FileInfo(m_ProducerConfigurationFileName);
      return ConfigurationDataFactoryIO.Load<ConfigurationData>(() => XmlDataContractSerializers.Load<ConfigurationData>(_configurationFile, m_TraceSource.TraceData), () => RaiseEvents());
    }

This method can attached to your instance of the ConfigurationFactoryBase (class derived from it) your custom configuration TypeParameter.
Because I had also a while to recover this idea I have decided to improve the implementation and make the ConfigurationFactoryBase generic to load any custom configuration. I have just finished the code and now I am going to improve the unit tests to provide examples for these two scenarios.

Anyway, you can immediately work on your custom configuration (inherited class or wrapper of ConfigurationData because the solution is ready and the improvement underway. Today I will commit the code, but the tests and kind of documentation will be available very shortly.

Piotr Szymczak
@Drutol
Okay thanks! I've managed to extend the configuration and build neat mechanism for configuring device models. I've unfortunately ran into issues with XML itself for some reason and I can't quite figure out why is it refusing to deserialize my array with additional configuration. As a placeholder I've thrown there JSON with the data with intention to get rid of it later.
Next step will be to prepare layout representing the boiler in form of image with added indicators once I've that I'll use the GPS coordinates to sort the boilers and show the nearest one.
With having that working I think I can write some docs and tests.
Mariusz
@mpostol
@Drutol I have closed: ConfigurationFactoryBase - should allow loading custom configuration #312

@Drutol as I said previously the code is ready to read any custom configuration derived from ConfigurationData or wrapping the ConfigurationData. Because you must provide the following function (LoadConfig() ) used to load configuration (Inverse of Control) you can define any type as the type parameter of XmlDataContractSerializers.Load<TypeParameter> that meets the requirements. Additionally, you are not obliged to use XmlDataContractSerializers.Load<TypeParameter>, so, for example, you may load the configuration from resources if applicable.

    private ConfigurationData LoadConfig()
    {
      FileInfo _configurationFile = new FileInfo(m_ProducerConfigurationFileName);
      return ConfigurationDataFactoryIO.Load<ConfigurationData>(() => XmlDataContractSerializers.Load<ConfigurationData>(_configurationFile, m_TraceSource.TraceData), () => RaiseEvents());
    }

This method can attached to your instance of the ConfigurationFactoryBase (class derived from it) your custom configuration TypeParameter.
Because I had also a while to recover this idea I have decided to improve the implementation and make the ConfigurationFactoryBase generic to load any custom configuration. I have just finished the code and now I am going to improve the unit tests to provide examples for these two scenarios.

Anyway, you can immediately work on your custom configuration (inherited class or wrapper of ConfigurationData because the solution is ready and the improvement underway. Today I will commit the code, but the tests and kind of documentation will be available very shortly.

It has be done and unit test contains examples how to deal with custom configuration.

Mariusz
@mpostol

@Drutol i am going to resolve #321 . The question is quite open and relates to composition. In your application you are using Autofac and all Export attribute have been replace by manual type registration. In current library implementation, all Importplaces are located in the custom code only so parts could be easily injected using Autofac container. I am not sure if after modification the library some imports will be located inside the library (my stuff). Is it possible to make available commonservicelocator side by side in your code to avoid using the Import attribute.

I want to fix #321 before final release of your code, but I am not sure if it feasible just now because it could have impact on the software architecture.

Piotr Szymczak
@Drutol
If everything boils down to adding ServiceLocator.SetLocatorProvider then there's no problem for me. From what I understood you want the library to compose itself using some IoC/DI container but avoid enforcing implementation on the final user with help of CommonServiceLocator?
Mariusz
@mpostol

@Drutol Let me give you an example where I need ServiceLocator:

    public UANetworkingConfiguration()
    {
      if (ServiceLocator.IsLocationProviderSet && ServiceLocator.Current != null)
      {
        IServiceLocator _locator = ServiceLocator.Current;
        this.TraceSource = _locator.GetInstance<ITraceSource>();
      }
      else
        this.TraceSource = new TraceSourceDefault();
    }

it is located in UAOOI.Configuration.Networking. If it is not implemented the code do nothing. In this example we only switch off tracing.
Because the library depends on the ServiceLocator I am expecting that you will provide implementation of ServiceLocator.SetLocatorProvider. I believe it is application responsibility to provide this implementation.

Have a look on UAOOI.Networking.ReferenceApplication.MEF.ServiceLocatorAdapter because it provides implementation for MEF in the ReferenceApplication. My expectation is that you will do similar implementation for Autofac if it is feasible. I am pretty sure someone has done it already.

For sure, I am not going to compose the library, but the library needs some services that should be provided by a central (singleton) application container. I believe that the application as one whole should have one IoC/DI container.

Does it make sense for you? Handling of the DI container is very important portability issue, so I hope we could find a common solution. Dedicated solution for tracing is located in

  [Export(typeof(INetworkingEventSourceProvider))]
  public class NetworkingEventSourceProvider : INetworkingEventSourceProvider

Have you implemented it and if yes where ? This way I can remove dependency on ServiceLocator if there are some good reasons.

Piotr Szymczak
@Drutol
Yeah, providing the implementation is the responsibility of the end application. I don't mind adding ServiceLocator and Autofac supports it "natively". So no issues here.
I've had issues with EventSource mechanism using Xamarin/Mono so I didn't do anything with these.
Mariusz
@mpostol

@Drutol Great to know that ServiceLocator is supported by Autofac. Do you have any Unit Test to prove it works for ITraceSource ?

Do you mean EventSource is not supported by the Xamarin/Mono. It is crucial statement, because it is breaking feature and should be reported as the issue and replaced by something else in the library. I hope it s only used in the Networking.UDPMessageHandler. Anyway we should not just neglect it for sure.

Piotr Szymczak
@Drutol
I didn't do any extensive research but the same code that was working on .Net Framework in console app wasn't working in Android's environment. I've always found the EventSource to be more of a Windows thing with EventViewer and such. It certainly doesn't see much use in case of Xamarin apps.
Mariusz
@mpostol
@Drutol What tracing mechanism makes sens for Xamarin. What about Azure ? I believe some kind of run-time diagnostic should be provided.
Piotr Szymczak
@Drutol
Recently I've been using Microsoft.Extensions.Logging which is an implementation of Microsoft.Extensions.Logging.Abstractions it may be more "generic".
And additionally they have multiple implementations depending on the platform like Microsoft.Extensions.Logging.AzureAppServices or Microsoft.Extensions.Logging.EventSource
So it would be up to the end application which provider to use while library would just reference the Abstractions
Mariusz
@mpostol
@Drutol I appreciate reporting this an new issue and adding this proposal. I will investigate it but it seems that now it is hard to make any rapid changes.
Mariusz
@mpostol
@Drutol I have noticed that EventSource is defined in System.Diagnostics.Tracing so it should have been provided on all platform. It seems that if something is in the Standard lib it must be recognized as generic enough. I have used implementation for files, but it is very likely that Azure implementation exists as well for any platform.
Anyway selection of a common tracing mechanism is very important and must be backward compatible because you are not the only user. Now 4.0 is ahead so we can make breaking changes but good reasons must be on table. In this case we must prove that Microsoft.Extensions.Logging.Abstractions is more abstract that System.Diagnostics.Tracing - first we must define how to measure abstraction to make comparison in an objective way.
Piotr Szymczak
@Drutol
Mariusz
@mpostol
@Drutol I completely agree with it would be up to the end application which provider to use while library would just reference the Abstractions. Now the library depends on the NETStandard.Library only and It seems we should keep it intact.
Piotr Szymczak
@Drutol
Hmm, I understand that the less dependencies there are the better. Not quite sure how we can go around it though... like with CommonServiceProvider
EventSources are "nono" in my opinion anyway as right now they are enforced logging solution for end application. And as it appears not every runtime supports them
Mariusz
@mpostol
@Drutol we have two issues for now so lets go step by step.
  1. EventSource- Report new issue related to EventSource and collect all your findings and proposals. It is good starting point for further investigation and decision making. Lets do nothing with your application for now. We can state that this feature is not available on mono and that's all. Let me know how it works for you. We should also check the feature against official .NET Standard compatibility table.
  2. CommonServiceProvider if it is supported by the Autofac you should only make sure that you have registered all contract providers I need and it can be marked as fixed as far as I follow this issue.
Piotr Szymczak
@Drutol
Okay, so what other providers do you require to be registered in CommonServiceProvider? I already have there things like UDPMessageHandler and the other 3 implementations I forgot the names of (config, bindings).
Mariusz
@mpostol
@Drutol It seems the ITraceSource is needed for now.