I have opnet 14.5 I am trying to find a Mobile Node with dual interfaces one for 802.11e (WLAN) and the other for 802.16e (Wimax) but it seems it is not there do opnet 14.5 has this node if no do I need special License ?.
thanks,
I would build a custom mode using OPNET Modeler with both interfaces in the model. You will have to design the connections and rules. Is it supposed to be a crossbanding relay or bridge or is it supposed to be a single endpoint node (like a computer) that acts as a source and sink only? Those are the questions you need to consider. If the latter case and you have a wired+wireless model, you might try replacing the wired interface with a WiMax interface, resulting in two transmitter/receiver pairs (WiMAX vs. WLAN). I'm not sure about the licensing (you will probably need Modeler + their wireless license among their plethora of license types), but I'm sure Riverbed/OPNET customer service will be happy to assist.
Related
The STM32 supply is very bad at the moment hence I am considering moving away from the STM32 and going for NXP since the supply is much better.
I would like to ask for advice regarding migrating from STM32 to NXP:
Have anyone tried to migrate their project from STM32 to NXP? Can this be done easily if the Core is the same?
What are the major difficulties that I may encounter?
Can I easily just remap pins, copy paste SPI/I2C and other drivers and they will just simply "work"
I have not gone through the migration, but consider that every single peripheral device (timers, Flash, SPI, I2C, etc) between two different micro manufacturers has a completely different register interface. This means that not a single thing works until you've implemented the new register interface. Usually this is handled by the manufacturers HAL, but those also have completely different C interfaces - so you're going to have to implement that, at the very least. So it's going to be a massive change no matter what. People who predict moving their code from one manufacturer to another usually build a porting layer in advance that hides the HAL, and swap out the HALs behind this layer. It mostly moves the development effort to another place (upfront) and starts reducing the work if there are more than 2 ports to maintain.
To get started it's best to have a quick look at the NXP HAL documentation on the peripherals you're using.
I believe it is possible to leverage the power of two USB Connected connected Google Coral TPUs in conjunction with one another (or at least side by side, running their own inferences each).
However, is it possible to leverage two or more Google Coral TPUs which are connected to separate Edge Devices but which sit on the same network connected by hard line ethernets & a switch?
Humn, there is no official API for doing this. So I guess I'll give you a more general answer.
You may want to look into kubenetes? I have not tried it, but it seems that they have supports for aarch64 which should works perfectly on the dev board.
Create servers and communicate via http? I actually have an opensource project calls restor, unfortunately it hasn't been maintained. But you may also check out doods.
Possibilities are endless :)
You may run multiple models on a TPU or also you may run multiple TPUs on a single device. Look into this:
https://coral.ai/docs/edgetpu/multiple-edgetpu/
If you would run multiple models on a TPU, the TPU will probably keep switching between models to load them. But, you may combine them using the compiler tool to avoid this.
If you would use multiple TPU devices on a single device, you may tell the interpreter instance which device you mean.
All the information are in the above link.
I'm wondering if for simply communicating with a PLC, like reading and writing tags, do I need all of the other heavy lifting that comes with an OPC-UA server?
I've tried writing a simple server in Python that talks to the PLC, but I get denied when requesting information from the PLC.
The Controllogix PLC I'm attempting to communicate with uses Ethernet/IP to communicate, so why doesn't a simple server/client script work? What is required exactly to communicate with an Allen Bradley PLC or PLC's in general?
There is quite a bit required to communicate with a PLC.
Each vendor has a driver, there are firmware compatibility considerations. Different protocols to think about.
OPC-UA makes it a bit more generic, but OPC-UA still has a set of things to work around when setting up communications.
Most of the OPC products I've worked with, needs to have their security adjusted to allow anonymous communication. It's generally bad practice to do this. (A network intrusion would be able to read/write to your automation layer) There is certificate signing and some encryption business that needs to be turned off if you're looking for simple communication. (Again, not a good practice but ok for learning)
After all that you have to have a notion of how your PLC is set up on your OPC server, there are channels, devices, namespaces etc. You'll point the OPC client to some opc.tcp://:
If you got this far you're almost done, I'm assuming your OPC server is running and has tags configured at this point. You can use your OPC-UA API to do a read. It can return just the value, or you can get an object back with tag health, timestamp, and a bunch of other data. Depends on the implementation. After that you can do subscriptions, writes...whatever else you need.
TLDR: OPC server not required, but may be the easiest method. Turn off security. (But turn it back on before exposing your control layer to the net)
I am also a little late to this conversation. If you are interested in coding your own solutions and don't want to use any of the commercially available standards, AdvancedHMI is a "mostly" open source solution written in VB.NET which is 100% free and provides communications to many different PLCs including the ControlLogix platform. Since I see you are programming in Python you may also be interested to know that the project does work under Mono on the Linux OS. I have used it to write gateways between EthernetIP and ModbusTCP and to pull data serially from OEM devices and push this data to a CLX PLC.
The forum is full of many helpful hints and is very active and supported.
Just trying to give you another option. DDE, NetDDE, FastDDE, OPC, DCOM, Suitelink.... These are all good, but mostly a pay to play adventure. As a programmer, it seems ridiculous to have to pay such an excessive amount of money just to talk to my hardware, IMHO. Sorry for the rant. Have Fun!
Update - Just wanted to also suggest the following open source project written in python:
https://github.com/dmroeder/pylogix
I have used this to write small programs for communicating with CompactLogix and ControlLogix. (Even to/from a RaspberryPi!)
Depends on several factors, if you want something simple to program you can opt for Modbus/TCP I think some AB PLC supports it without extra hardware.
However if you want something with more security for example for industrial use then OPC UA would be better choice but the programming has a complexity far higher than Modbus, even using the libraries of OPC Foundation or others. There is the option of using a commercial or free (if any) OPC UA server to save work, then you will need to program the client side only.
With Ethernet/IP it should also be possible, but the problem is that there is no clear specification and even different AB models talk different Ethernet/IP dialect ! , it is also far more complex to program than Modbus.
I am a little late to this discussion, but there are a couple commercial tools that make this a bit easier. The one that comes to mind for me when you say you are using python is Cogent's data hub. It is certainly not the cheapest tool out there, but they have already done all of the heavy lifting for PLC/PC communications & security.
If trying to read CLX data using Python, there are several open source implementations that will save you a lot of work. Such as this:
https://github.com/dmroeder/pylogix
If you use .NET and Visual Studio, you can use AdvancedHMI
to be able to read and write OPC Tags to ControlLogix platform is done via its communication Driver RSLinx. RSLinx acts as an OPC Server, it will need to be configured to communicate with the PLC and run on a networked PC on the same LAN. Several flavours of RSLinx are available (for WAN/VLAN also) but essentially this is the communications driver you need to talk to AB PLC's
Has anyone used CKO_VENDOR_DEFINED to create a key or a data object?
There is hardly any documentation (including the mother load from Oasis) about how to do it, or which attributes are applicable/not-applicable.
Unfortunately, but hopefully understandably, I can not describe exactly what I am trying to do.
But the gist of it is that I need to be able to have a bit more attribute<=>mechanism flexibility with our kind of keys and the ability to modify a key on the token.
I'd really appreciate any pointers or help.
You can take a look at OpenPGP extension to PKCS #11 where CKC_OPENPGP is defined as:
#define CKC_OPENPGP (CKC_VENDOR_DEFINED|0x00504750)
I've seen also commercial implementations introducing CK*_VENDOR_DEFINED extensions this way.
(AFAIK) vendor defined object types must be implemented inside the HSM unit firmware (in theory, the host-side cryptoki library could introduce some additional "virtual" object types, but this probably would not make any sense as the overall security model would stay the same -- because the host-side cryptoki code runs in an untrusted execution environment).
If you need more control than provided by the vanilla PKCS#11 you have some choices:
Use existing vendor extensions -- some vendors add their own extensions designed to solve common use-cases. Read your documentation or contact your vendor directly.
Implement a custom firmware -- some products allow the end-user to run a custom code inside the HSM device. You can implement your model this way.
SafeNet ProtectServer:
SafeNet ProtectServer HSMs offer a unique level of flexibility for
application developers to create their own firmware and execute it
within the secure confines of the HSM. Known as functionality modules,
the toolkits provide a comprehensive facility to develop and deploy
custom firmware.
Thales nShield:
Most nShield HSMs also support the unique ability to host critical
applications within the hardened security boundary, so you can
establish tamper-resistant business processes in addition to
protecting cryptographic operations.
Utimaco CryptoServer:
The CryptoServer Software Development Kit (SDK) is the professional
development environment for all Utimaco Hardware Security Modules. It
enables integrators and end-users to create specific applications,
e.g. proprietary algorithms, custom key derivation procedures or
complex protocols that run in the tamper-proof environment of the
CryptoServer Hardware Security Module. As the SDK provides full access
to the Utimaco base firmware, custom firmware modules can be developed
in a very short time frame.
Use some other technology -- do not use HSMs at all and leverage some other secure device. Specifically smartcards might be a viable alternative as some of them can be programmed (at least Java Card or MULTOS ones). On the other hand the performance and range of supported algorithms is quite limited here (depends on your use-case).
I recently posted a question about Azure... is it really an OS? I understand the technical details, and I got a lot of fuzzy answers... I really want to know... what do you think is the difference between an OS and a Framework?
Just for reference, Azure will be built on top of Hyper-V servers and the virtual machines will be running vanilla Windows Server 2008. It will run services that creates a cloud on top of the many virtual machines which is called Azure. Windows is calling Azure an OS.
I am trying to understand how to define the difference between an OS and a framework.
Operating System: The infrastructure software component of a computer system
Framework: A re-usable design for a software system (or subsystem).
By these definitions it seems to me, that an operating system can be built using a framework, and a framework can be built to interact with an operating system.
Singularity is an example of an experimental OS that is built using managed code.
Framework is a very broad term, it can be used to describe many types of subsystems. It could even describe an operating system.
Operating System is more specific, it implies facilitation of interaction with a computers or group of computers hardware layer, through the use of human user interfaces. I think Azure fits this description.
It's up to marketing - I don't think the terms have a definite meaning any more.
Is a JVM a framework?
What if it's running on a raw uC or even an FPGA - is it an OS?
An OS is the thing that directly interfaces with the machine, be it virtual or real. It has to expose syscalls that handle input devices, output devices, sound, networking, and all the other things that we take for granted these days. It also often provides some kind of UI which uses these services to make it easy to use/useful for an end-user. It needs to have device drivers to work with video cards, sound cards, etc. (Once again, these can be virtualized).
A framework is... something built on top of the OS. It, too, exposes an API, but they are often not so low-level as the one the OS exposes.
frameworks provide api contracts that oses usually don't - meaning they sit atop the os, hide and manage the differences, and consequently give you that platform independence goodness that can broaden our target audience
A framework thought to be as a development environment,a helping platform for further developments and you can work additively to create some other application using components of framework, while OS is system software is an environment to operate a system.