Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[basyx-dev] Various BaSyx questions

Dear BaSyx development team,

I have multiple questions regarding features and best practices of BaSyx:

For my industry 4.0 prototype, I have Submodels that are shared between Administration Shells (e.g. Manufacturer and User connected to some shared submodels).
I wonder, what is the canonical way of handling this use case with BaSyx?
I thought it was possible to only deploy the shared Submodels once, and then retrieve them thanks to the endpoint being present in all concerned Administration Shell, however the MultiSubmodelProvider seems to only be able to retrieve locally deployed submodels when looking for all its submodels.

What I did here, was to create two separated servlets, one for all submodels, and one for all administration shells (meaning the submodels were only created on the submodel servlet, the AAS one only contained AAS high-level info + the submodel descriptors with submodels IDs and endpoints).
Is it acceptable to use this type of infrastructure?

I wondered if in that case, the MultiSubmodelProvider could, when called, should look at all its linked resources (i.e. remote submodels) and then request them dynamically?
Or perhaps each Administration Shell should have its own version of the remote submodels and update them when called?
Or perhaps it is completely wrong, and submodels should be accessed manually in that case?


On a different subject, I have remarks regarding the SQLDirectoryProvider:
- Consulting the registry REST API, it only seems to implement the get all AAS call (not the call to get a specific AAS id, nor its submodels, etc.), are the other calls to be implemented on a later BaSyx version?
- The call to get all AAS doesn't seem to work as intended, it returns a malformed json string (no ',' separators between AAS, no overall list structure "[]") instead of a List<AASDescriptor>, which makes the calls to AASRegistryProxy.lookUpAll not working


Best regards,


Nicolas Duminy


Back to the top