I'm a newbie to Autosar and I would like to understand how V2X communication stack is considered in "Adaptive Platform". Will that become a "Native platform service" (or) It shall remain as "Non Platform Service".
I could not see any related materials in autosar website.
I think It will still be considered as an "Adaptive Platform" in the automotive ecosystem. There are a lot of stakeholders in the V2X Tech, for instance:
Chip manufacturers, Stack Providers, OEM integrators, Standart Regulators.
So, It will be really hard to become a "Native platform service"
Related
An article on Hackaday piqued my curiosity, and I see Kinect + Linux questions being asked here (mostly about configuration), so I'll venture this question:
It is clear to me that Kinect can be used together with Linux on a "regular pc" -- but I can't help wondering why, that is, what might you actually use this for?
I don't suppose people really like the human/computer interface presented in movies such as "Minority Report" -- surely, nobody is actually doing text editing, coding, or business data processing by "hand-waving". So besides just games & exercises, what are examples of actual, real-world, useful (ie. 'professional') applications of such a setup?
For instance, can it be used for 3D scanning of real-world objects to obtain digital models? What sort of accuracy would such a scan yield?
The Kinect can be used for a wide variety of useful applications. I'm not sure if you are asking specifically about Linux or if Windows ("regular PC") is acceptable, but I'll provide you with some examples that come to mind.
For Linux specifically, it is likely that applications on Linux are using the sensor's raw sensor data only, rather the skeletal tracking feature. Many Kinect applications are on Windows because Microsoft's Kinect SDK is available only on Windows, and it provides the best skeletal tracking accuracy to-date.
You are right that the Kinect is rarely used where a keyboard & mouse would be faster and more accurate, but note that it is potentially relevant for accessibility.
And yes, it can be used for 3D scanning of real-world objects. I'm not sure about the exact accuracy, but I think it is acceptable for many applications. The main benefits are its low cost and speed.
For examples of 3D scanning, check out:
KinectFusion, a Microsoft Research project
Occipital Structure sensor for 3D scanning. (This is not the Kinect sensor, but provides an example application for 3D scanning. The company has a Kinect-related history as well.)
Styku - 3D body scanning for clothes fitting
Aside from 3D scanning, here are some other examples of applications:
Atlas5D - at-home patient monitoring
GestSure - 'Minority Report' interface for surgical rooms
Jintronix - games, exercises, assessments for physical therapy
There are many depth sensors like the Kinect3D on the market. The latest notable application would be iPhone X's depth sensor and FaceID. Many companies in the space are working actively in FaceID now, which would also be useful on Linux. Check out Microsoft's Window Hello biometric facial ID system - see Microsoft's official website:
Manufacturing of the Kinect sensor and adapter has been discontinued,
but the Kinect technology continues to live on in products like the
HoloLens, Cortana voice assistant, the Windows Hello biometric facial
ID system, and a context-aware user interface.
Kinect has applications in the robotics community as well, though I don't know the specifics. I assume many in robotics community use Linux when working with the Kinect. The depth and color cameras can be used to provide vision and the microphone array for audio input.
Generally, the Kinect had a big impact when it was released not just because of its technology but also because of its low price point, even if it's not the most accurate for every application. As this technology improves, I hope many other applications will emerge and become mainstream.
EDIT: also, check out this Hacker News discussion: "Microsoft Has Stopped Manufacturing The Kinect"
Is there a protocol which point-of-sale machine use to talk to a credit card machine? What is the recommended software/hardware platform to prototype a point of sale system?
There are several protocols available, here are some of then: First there is OPI, Open Payment Initiative, specified by Wincor Nixdorf. It is in wide use. Then there is the german ZVT protocol or the Swiss VEZ protocol. It really depends in which region you plan to use it, the protocols I listed definitel are in widespread use in Europe.
It would be easier to get the sdk of your payment gateway and integrate it into you software. I have hooked ip VeriFone, Clover and Priority machines. Each vendor has multiple APIs in different languages.
So far, I've used many different Audio Production software on Mac and Windows platforms. Often times, I ponder on the idea of creating my own DAW, but I realize that would be an extremely difficult challenge for a single person to undertake (especially if only knowledgeable in one particular area / language of programming).
There's a flood of ideas / features that comes to my mind just by the thought of some of the other DAWs I've used. From implementing MIDI in/out, Audio Routing, Mix Buses, VST support, User Interface for a Piano Roll and Song view, etc...
So my question is...
Which roles would be required in a team of developers to create a complete Digital Audio Workstation (DAW) Software?
I think the right answer is several good developers (you don't need so many, perhaps 3) a good product manager, an ui designer/graphist a lot of testers. And a good coffee machine.
The real problem is what kind of DAW do you want, portable on mac and windows, which OSs, which formats (vst 2, 3, AU, RTAS, AAX, rack extension, DX), do you want only MIDI and adio tracks, which external MIDI devices you want to support, do you support OSC, other protocols?
What will be the features of you mixer, integrated effects? What support of audio API on windows (wasapi, asio ...) do you want some cloud feature ? community or online store integration?
What kind of breakthrough would you have compared to cubase, live, PT, DP, Logic, garage band, bitwig, studio one, sonar, fl studio ...? Do you want modular patches or just tracks? Will you have advanced integrated controls or midi modifiers?
All that is the problem...
This is a very complex question!
I'm doing a grad-school software engineering project and I'm looking for the protocol that governs communications between ATMs and bank networks.
I've been googling for quite a while now, and though I'm finding all sorts of interesting information about ATMs, I'm surprised to find that there seems to be no industry standard for high-level communications.
I'm not talking about 3DES or low-level transmission protocols, but something along the lines of an Interface Control Document; something that governs the sequence of events for various transactions: verify credentials, withdrawal, check balance, etc.
Any ideas? Does anything like this even exist?
I can't believe that after all this time the banks and ATM manufacturers are still just making this up as they go.
A shorter question: if I wanted to go into the ATM software manufacturing business, where would I start looking for standards?
Well, there are lots of interbank networks. I would guess that each of them communicate differently. The stickers on the ATM (Cirrus, STAR, Pulse, etc...) identify which network the machine participates in. I do believe, though, that the "structure" of the message is dictated by an ISO standard. Cirrus is a Mastercard owned network and PLUS is a Visa owned network... I'd scour their sites to see if they publish any API details.
Edit, by request:
Have a look at the following ISOs 15022, 20022, 9362 and 4217 -- http://en.wikipedia.org/wiki/Category:Financial_routing_standards
ISO 8583 is dominant.
Also, take a look at EMV.
The ATM to bank link can be proprietary or standard. It is only upstream where inter-organisation wire level interoperability is needed, that standards become always necessary.
ISO 15022 definitely doesn't cover ATM to bank. So far, it covers further upstream. And is now superseded by ISO 20022 - "originally named ISO 15022 2nd edition".
ISO 20022 covers the total scope of financial services, and acts as a super forum for ISO financial services protocols.
There are two basic protocols, ISO8563 and IFX (a financial XML subset) but many banks us protocols supplied by the vendor, because these include Device driver protocols that drive the ATM 'States', There is also a reporting protocol where the ATM reports its cash and usage statii.
Does anyone know of any resources that can give me an idea of how widely various JSRs are implemented?
Links
Which phones support which spec
There are a few options none of them are complete :(
J2mePolish's db
Device Atlas
WURFL
Nokia, Sony-Ericsson,* providers websites.
This information isn't aggregated any where really but for JRS information I would say j2mepolish has the greatest source of this information with +- 1000 devices. Although Wurfl and DA have more devices they are mostly targeted and WAP+Mobile Web developers
JBenchmark is quite a substantial database of API compatibilities.
www.jbenchmark.com